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Section  1 


COURSE  OBJECTIVE 

The  purpose  of  AFIT  Course  ST'S  100,  Introduction  to  Acquisition  Management, 
is  to  increase  the  effectiveness  of  Air  Force  Personnel  entering  the  held  of  Systems 
Acquisition  for  the  first  time.  It  provides  the  foundation  for  furt  her  learning  on  the  job 
and  in  other  specialized  courses.  Current  concepts  and  problem  areas  in  the  acquisition 
process  are  explored  throughout  the  course. 

The  objectives  of  the  course  are  for  eacli  student  to  know: 

a.  The  environment  in  which  defense  systems  are  acquired. 

b.  The  organization,  mission,  am!  iv'-poie-tbil'iiie-.  >■!  the  i • ' ■  ■  i  ><u  ■  •  il » ‘ 

c.  The  \  vvai'u'.in  ot  -oMem--  nmur-ii  vu 


Section  2 

COURSE  DESCRIPTION 

SYS  100  consists  of  video  lectures  and  group  discussions  in  two  main  subject 
areas.  The  first  area  includes  an  overview  of  the  Acquisition  Process  including  presenta¬ 
tions  on  the  types  of  acquisition  programs;  the  program  manager’s  role;  the  program 
management  organization;  the  program  management  environment;  the  acquisition  pro¬ 
cess:  the  Planning,  Programming,  and  Budgeting  System  (PPB>j\  the  Solicitation  pro¬ 
cess:  the  Contracting  process;  and,  the  Communication  Exercise.  The  second  area 
includes  an  overview  of  the  roles  of  the  major  functional  disciplines  within  the  program 
office.  In  this  area,  the  disciplines  of  Systems  Engineering,  Integrated  Logistics  Support 
(ILS),  Configuration  Management,  Data  Management,  Manufacturing  Management,  Test 
and  Evaluation,  and  Program  Control/Cost  Estimating  are  discussed.  Details  of  each  les¬ 
son  nro  provided  in  Section  7  of  this  syllabus. 


Section  3 

COURSE  OUTLINE 


Lesson  or  Activity  number  of  hours 

a.  Course  Registration/Orientation .  1 

b.  Introduction  to  Acquisition  Management .  1 

c.  Internal  Program  Management . : .  1 

d.  External  Program  Management .  I 

e.  Acquisition  Process .  2 /> 

f.  Planning,  Programming,  and  Budgeting  System .  3 

g.  Solicitation  Process .  I 

li.  Contract  Management .  2 


vi 


i.  Communication  Exercise .  1.5 

j.  Test  #1  and  review .  I 

k.  Systems  Engineering .  2 

l.  Integrated  Logistics  Support  .  2 

in.  Configuration  Management .  2.5 

n.  Data  Management .  1 

o.  Manufacturing  Management .  2 

p.  Test  and  Evaluation .  2 

q.  Program  Control/Cost  Estimating .  1.5 

r.  Test  #2  and  review .  1 

s.  Course  Summary,  Critique  and  Graduation .  1 


Total  30 


Section  4 

ADMINISTRATIVE  INFORMATION 

a.  Attendance  Policy: 

While  attending  this  course,  students,  including  local  area  students,  are  in  a  TDY 
stains  to  AEIT  and  are  thus  responsible  to,  and  under  the  supervision  and  administra¬ 
tion  of  the  Dean,  School  of  Systems  and  Logistics.  The  Dean  has  prescribed  that  stu¬ 
dents: 

(1)  Will  be  present  in  class  at  the  designated  hours. 

(2)  Will  be  excused  from  attendance  only  if  ill,  or  as  otherwise  excused 
by  the  course  director. 

(3)  Be  aware  that  dental  appointments,  vehicle  maintenance,  committee 
meetings,  requirements  of  a  regularly  assigned  job,  etc.,  are  not  normally  valid 
causes  for  class  absence. 

(4)  Will  notify  the  course  director  or  the  class  leader  of  location  or  desti¬ 
nation  if  leaving  the  local  area  during  weekends. 

b.  Instructional  Methods,  Academic  Freedom,  Nonattribution: 

Classroom  videotape  presentations  are  made  by  faculty  members  of  the 
School  of  Systems  and  Logistics  and  by  selected  guest  speakers.  Course  facilita¬ 
tors  are  provided  to  enhance  the  material  presented  including  class  discussions. 
Instructional  methods  include  videotaped  lecture,  discussion,  demonstration, 
performance,  exercise  and  related  instruction. 

|'h<  comae  facilitator,  guc-t  led  uni--,  and  each  student,  within  the  bounds  of  cour- 
te-.\  and  propriety,  is  encouraged  to  participate  and  freely  discuss  the  subject  matter 
presented.  Case  histories  or  examples  of  actual  practice  are  for  illustration  and  class¬ 
room  discussion  only  and  are  strictly  on  a  nonattribution  basis. 


vii 


(1)  Academic  freedom:  The  privilege  of  debate  with  discretion  on  any  subject 
related  to  curricula  within  the  school  forum. 


(2)  Non- attribution:  Treating  statements  made  in  the  school  forum 
privileged  information  not  to  be  attributed  to  a  specific  individual  when  outside  the 
school  forum. 


c.  Student  Preparation:  Student  are  expected  to: 

(1)  Read  scheduled  assignments  in  advance. 

(2)  Remain  alert  and  attentive  in  class 

(3)  Take  notes.  Notes  in  your  own  words  add  greatly  to  your  retention 
of  material  presented. 

(4)  Participate  actively  in  discussions,  but  please  do  not  monopolize  or 
sidetrack  them. 

(5)  Remember  that  some  of  the  speakers  are  our  guests  and  are  contri¬ 
buting  their  time  and  efforts  to  aid  our  program.  Treat  them  accordingly. 


d.  Class  Leader.  On  the  first  day  of  class  a  class  leader  will  be  appointed.  The 
class  leader  will  be  the  senior  military  class  member  or  the  senior  civilian  class  member 
when  no  military  are  present.  The  class  leader’s  basic  responsibilities  include: 

(1)  Maintaining  classroom  decorum. 

(2)  Monitoring  class  attendance  (see  AF1T  Form  67). 

(3)  Serving  as  a  focal  point  to  provide  student  feedback  on  the  content 
and  conduct  of  the  course  to  the  course  director  and  the  department  head. 


e.  Student  Evaluation  of  Course :  There  are  four  principal  means  of  obtaining 
student  evaluation  of  the  course  content  and  conduct. 

(1)  Direct  feedback  to  the  course  director  at  any  time  and/or  at  the  final 
class  session. 

(2)  Student  end-of-course  written  appraisal  submitted  at  the  final  class 
session. 

(3)  Student  class  leader  debriefing  on  the  last  class  day  with  the  depart¬ 
ment  head. 

(4)  Post-course  (approximately  6  months)  surveys  of  selected  classes. 


Section  5 

EVALUATION  CRITERIA/GRADING  POLICY 

The  School  of  Systems  and  Logistics  (LS)  ofTers  no  academic  credit  for  the  SYS  100 
course.  The  course  is  evaluated  on  a  pass/fail  basis  only.  The  students  will  be  evaluated 
by  a  quiz  and  a  final  examination.  The  quiz  will  cover  the  material  in  the  first  block  of 
instruction,  and  the  final  examination  will  cover  all  of  the  material  in  the  course.  The 
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student’s  final  grade  for  the  course  will  be  determined  by  the  student’s  performance  on  both  the 
quiz  and  the  final  examination  The  quiz  will  be  1/3  of  the  final  grade  and  the  final  examination 
will  be  2/3  of  the  final  grade.  A  combined  grade  of  60%  is  required  to  pass  the  course.  Stu¬ 
dents  completing  this  course  will  be  issued  grades  of  S'  (Satisfactory)  or  V  (Unsatisfactory) 
reflecting  their  performance  during  the  course.  Students  who  are  unable  to  complete  the  course 
will  be  issued  a  grade  of  ^(Withdrawn) 


Section  6 

CLASS  SCHEDULE 


The  detailed  class  schedule  for  the  course  varies  with  each  offering.  Therefore,  each  stu¬ 
dent  is  given  a  copy  of  the  class  schedule  during  the  class  registration  period. 


Section  7 

INDIVIDUAL  LESSON  PLANS 

The  remainder  of  this  document  is  a  detailed  description  of  each  lesson  in  the  SYS  100 
course.  The  following  is  a  simple  explanation  of  key  parts  of  the  syllabus  lesson  plan  page  that 
should  be  of  great  interest  to  the  student. 

a.  Time  Approximate  number  of  classroom  hours  to  be  spent  on  the  lesson. 

b.  Lesson  Objective:  A  broad  statement  of  the  ultimate  student  outcome. 

c.  Samples  of  Behavior:  Specific  identification  of  what  each  student  should  be  able  to  do 
at  the  completion  of  a  lesson. 

d.  References:  Major  documents  used  as  source  data  for  leason  content. 

e.  Instructional  Material:  A  listing  of  the  materials  the  student  is  provided  as  a  routine 
part  of  the  curriculum.  However,  students  may  receive  additional  supplemental  materials  during 
the  conduct  of  the  class.  LInless  otherwise  specified,  this  supplemental  material  is  optional  and 
non  testable. 

f.  Student  Preparation:  Actions  the  student  must  accomplish  before  a  particular  lesson  is 
formally  presented  in  class. 
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LESSON  1 


LESSON  TITLE:  Introduction  to  Acquisition  Management 
TIME:  1  hr 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
what  is  meant  by  the  terms  acquisition  program,  program  direction,  and 
system;  the  role  of  the  Statement  of  Operational  Need  (SON); 
and  the  three  categories  of  Air  Force  acquisition  programs. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Define  acquisition  program. 

b.  State  the  kind  of  appropriations  used  to  fund  acquisition  programs. 

c.  Describe  a  system. 

d.  State  the  vehicle  for  validating  an  operational  need. 

e.  State  the  purpose  of  the  System  Operational  Requirements  Document 
(SORD),  and  Depot  Support  Requirements  Document  (DSRD). 

f.  State  the  primary  vehicle  for  program  direction  from  I  IQ  USAF  to  the 
Major  Command  Headquarters. 

g.  List  and  describe  the  primary  criteria  for  the  three  categories  of  Air 
Force  Acquisition  Programs. 

TOPIC  INTRODUCTION: 

The  government  is  a  very  large  user  of  supplies  and  services  purchased  in  the 
market  place.  With  the  high  quantity,  complexity,  and  costliness  of  items  purchased  by 
the  Government,  the  requirements  placed  upon  the  acquisition  community  are  growing 
more  and  more  demanding.  This  lesson  introduces  some  fundamental  terms  and  con¬ 
cepts  necessary  to  understand  the  acquisition  process.  Critical  to  understanding  how  an 
acquisition  program  works  is  understanding  what,  exactly,  an  acquisition  program  is  and 
is  not.  An  acquisition  program,  in  this  course,  is  not  the  procurement  of  base  level  sup¬ 
plies  or  services  (like  food,  linens,  or  toilet  paper,  for  example)  that  are  common  to  every 
Air  Force  base.  Rather,  an  acquisition  program  deals  with  research,  development,  test 
and  evaluation,  procurement,  and  security  assistance  programs  in  providing  a  new  or 
improved  capability. 

The  type  of  funds  used  in  acquiring  these  weapon  systems  are  introduced  as  back¬ 
ground.  Buying  a  weapon  system  means  the  acquisition  of  not  only  the  system 
hardware,  but,  also,  the  acquisition  of  data,  training,  spares,  and  all  other  elements 
required  to  operate  and  maintain  the  weapon  system.  Several  documents  are  introduced 
that  initiate  the  acquisition  process  and  the  documents  purpose  in  the  program  life-cycle. 
Finally,  the  different  types  of  Air  Force  acquisition  programs,  and  their  criteria,  are  dis¬ 
cussed,  highlighting  the  fact  that  not  all  acquisition  programs  are  the  same  (i.e.,  some 
may  have  higher  or  lower  priority  than  your  program). 

Think  of  this  lesson  as  the  starting  point  in  a  new  program.  Imagine  a  program 
that  is  just  getting  off  the  ground  and  you  are  the  program  manager.  You  have  very 
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little  acquisition  experience  and  you  are  taking  this  accelerated  course  to  bring  you  up  to 
speed  on  what  is  happening  all  around  you.  (Sound  familiar?)  Assume  that  voui  pio- 
gram  meets  a  validated  need  and,  now,  you  are  ready  to  learn  basic  knowledge  necessary 
to  manage  your  program. 

METHOD  OF  INSTRUCTION:  Lecture 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  The  Acquisition  of  Major  Systems,  by  Mr  McCarty,  AFIT/LSY 

b.  Article,  Operational  Requirements  Process ,  by  Capt  Andrews 

c.  Introduction  to  Acquisition  Management  videotape 

d.  Lesson  view  graphs 

AUDIO- VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 


REFERENCES: 

a.  DOD  Directive  5000.1,  Major  System  Acquisition 

b.  AFR  800-2,  Acquisition  Program  Management 

c.  AFR  57-1,  Operational  Requirements:  Operational  Needs  Requirements, 
and  Concepts 

d.  AFSCP  800-3,  A  Guide  for  Program  Management 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  The  Acquisition  of  Major  Systems 

b.  Read  article:  Operational  Requirements  Process 

c.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1,  Discuss  the  concept  of  the  "system"  as  used  in  the  Air  Force  acquisition  process. 
Why  is  this  important  for  management? 


2.  Describe  the  term  "validated  need"  and  state  the  vehicle  for  validating  a  need. 


3.  Describe  the  primary  criteria  for  the  categories  of  Air  Force  Acquisition  pro¬ 
grams. 


[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 


ACRONYMS 


[The  following  acronyms  are  first  used  and  identified  in  this  lesson] 
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ADM 

AFDAP 

AFSARC 

Cl 

DAB 

DAE 

DCP 

DPML 

DSRD 

DT&E 

FYDP 

IOC 

IOT&E 

IPS 

JSOR 

LRIP 

MAJCOM 

MNS 

OPR 

OTSE 

PDP 

PM 

PMD 

PMRT 

PO 

POM 

PPBS 

P3I 

RCM 

RDT&E 

RFP 

SCP 

SECDEF 

SOA 

SON 

SORD 

SPO 

TS.E 


Acquisition  Decision  Memorandum 
Air  Force  Designated  Acquisition  Program(s) 
Air  Force  System  Acquisition  Review  Council 
Configuration  Item(s) 

Defense  Acquisition  Board 

Defense  Acquisition  Executive 

Decision  Coordinating  paper 

Deputy  Program  Manager  for  Logistics 

Depot  Support  Requirements  Document 

Development  Test  and  Evaluation 

Five  Year  Defense  Program 

Initial  Operational  Capability 

Initial  Operational  Test  and  Evaluation 

Integrated  Program  Summary 

Joint  Systems  Operational  Requirement 

Low  Rate  Initial  Production 

Major  Commands 

Mission  Need  Statement 

Office  of  primary  Responsibility 

Operational  Test  and  Evaluation 

Program  Decision  Package 

Program  Manager 

Program  Management  Directive 
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SECTION  I 
INTRODUCTION 

Military  managers  of  system  acquisitions  often  find  themselves  in  the  spotlight 
because  of  news  stories  about  cost  overruns,  project-  delays,  ami  technical  iUllictilties. 
The  scrutiny  and  exposure  which  the  military  program  manager  (I’M)  receives  is  correct 
and  fundamental  to  our  system  of  government,  but  this  examination  makes  the  program 
manager’s  job  additionally  demanding  and  complex.  In  fact,  directing  the  acquisition  of 
a  major  defense  system  ranks  high  among  the  most  complex  challenges  facing  managers 
anywhere  in  our  society.  This  paper  is  an  attempt  to  outline,  in  broad  terms,  the 
environment  in  which  the  PM  operates,  the  direction  he  [l]  follows,  and  the  decision  pro¬ 
cess  which  controls  the  program  --  all  in  the  context  of  the  life  cycle  of  a  typical  major 
program. 


SECTION  II 

SYSTEM  ACQUISITION  MANAGEMENT 

A  weapon  or  support  system  is  more  than  just  the  mission  equipment;  a 
weapon/support  system  includes  peculiar  support  equipment,  supplies,  spare  parts, 
technical  orders  and  manuals,  training  programs  and  training  equipment,  etc.  (See  Fig¬ 
ure  1).  Therefore,  in  a  system  development,  all  the  many  elements  must  be  considered, 
developed,  and  procured  so  that  together  they  provide  an  operational  capability.  System 
acquisition  management  is  the  process  whereby  the  diverse  tasks,  functions,  and 
resources  required  are  integrated  and  focused  upon  the  development  of  a  necessary  capa¬ 
bility  on  time  and  within  budget. 

A  key  concept  of  system  acquisition  management  is  the  designation  of  a  single 
manager  to  be  responsible  for  all  of  the  technical  and  business  aspects  of  a  program. 
That  manager  must  then  assemble  a  team  to  assist  in  accomplishing  the  program  objec¬ 
tives.  The  management  team  is  formed  by  drawing  personnel  from  all  of  the  appropriate 
functional  areas  and  placing  them  under  the  control  of  the  program  manager  {PM).  The 
program  manager  is  given  the  authority  required  to  carry  out  his  responsibilities  and  is 
held  accountable  for  the  accomplishment  of  the  total  management  task.  For  example:  a 
yearly  budget  must  be  prepared,  defended,  and  managed;  schedules  must  be  developed 
and  adhered  to  (or  deviations  must  be  justified);  mission  hardware  must  be  designed, 
developed,  tested  and  produced;  a  capable  logistic  support  system  must  be  assured; 

1  Whenever  the  words  hr  or  him  appear  in  this  paper,  except  in  reference  to  a  specific  person,  it  should  be  under¬ 
stood  that  like  or  fcrr  may  be  substituted 


1-4 


Figure  1 


AEROSPACE  vehicle 


contractors  must  be  selected,  and  contracts  negotiated  and  administered.  The  team 
operates  through  a  system  program  office  ( SPO )  (See  Figure  2).  The  SPO  is  headed  by 
the  program  manager,  who  reports  to  a  senior  defense  executive.  Thus,  the  SPO  is 
removed  from  the  basic  functional  structure  and  the  PM  is  provided  a  discrete  line  of 
authority  so  that  the  broad  and  multiple  requirements  of  system  acquisition  can  be  met. 
Central  to  the  system  management  concept  is  the  philosophy  that  the  PM  must  serve  as 
the  overseer  of  the  broadest  Air  Force  interests  in  order  to  develop  the  most  effective 
solution  to  mission  needs  through  the  efficient  use  of  the  available  resources.  That  entails 
focusing  the  various  functional  skills  available  within  the  SPO  team  upon  the  achieve¬ 
ment  of  a  common  goal,  and  balancing  a  variety  of  requirements  to  avoid  compromising 
that  goal.  Ideally,  each  program  will  develop  and  produce  the  most  effective,  easily  sup¬ 
ported,  reliable,  technologically  advanced,  yet  cheapest  and  simplest  solution  to  our  mis¬ 
sion  needs  and  will  do  it  in  record  time.  Unfortunately,  those  goals  are  not  all  mutually 
supporting  and  it  is  the  PM  who  must  provide  the  perspective  to  represent  each  of  the 
goals  so  as  to  achieve  an  affordable,  supportable,  and  effective  system  in  time  to  meet  the 
need.  The  program  objectives  are  defined  by  the  Air  Force  and  approved  by  the  Secre¬ 
tary  of  Defense  ( SECDEF ).  Therefore,  the  essence  of  the  program  manager’s  role  is  to  be 
the  agent  of  the  Service  in  the  management  of  the  system  acquisition  and  the  focal  point 
of  authority  and  responsibility  for  running  the  program. 


It  is  a  truism  that  each  system  acquisition  program  has  its  unique  features  and, 
therefore,  no  two  programs  are  identical.  For  example,  differences  in  technology,  cost, 
schedule,  priority,  and  funding  are  normal  and  must  be  accommodated.  However, 
despite  the  differences,  there  is  a  basic  process  or  cycle  common  to  all  programs,  and  that 
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TIGURE  2 

is  what  this  paper  will  discuss. 

System  acquisition  programs  go  through  a  sequence  of  key  program  decisions,  mile¬ 
stones,  and  activities  known  as  the  system  acquisition  process  or  system  acquisition  life 
cycle  (See  Figure  3).  The  system  acquisition  life  cycle  is  essentially  a  logical  flow  of 
activity  representing  an  orderly  progression  from  an  identification  of  system  need  to  final 
operational  deployment.  Each  PM  must  be  prepared  to  develop  a  tailored  management 
approach  which  will  achieve  an  operational  capability  with  the  most  effective  use  of  the 
resources  and  time  available.  Each  of  the  phases  may  involve  a  recycling  of  effort  until 
the  output  of  the  phase  is  optimized.  If  appropriate,  life  cycle  phases  may  be  combined 
or  omitted.  Some  programs,  where  technology  is  well  developed,  may  enter  the  life  cycle 
in  mid-stream.  Each  phase  is  designed  to  develop  a  level  of  confidence  in  the  solution(s) 
»  offered  and  to  reduce  the  risks  involved  in  proceeding  to  the  next  phase.  Outputs  of  each 

phase  constitute  a  definitive  and  documented  baseline  for  entry  into  the  next  phase.  The 
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life  cycle  is  distinguished  by  an  incremental  commitment  of  resources.  As  the  system 
evolves,  each  decision  milestone  is  directed  to  commitment  of  increased  resources  predi¬ 
cated  upon  the  achievement  of  defined  objectives.  The  milestone  objectives  are  designed 
to  reduce,  through  demonstrated  performance,  the  risks  (cost,  technical  and  schedule) 
inherent  in  a  new  acquisition  and  provide  an  information  base  for  decisions  to  proceed 
with,  redirect,  or  terminate  programs. 


FIGURE  3 


Figure  3 

Policy  for  major  system  acquisitions  by  DOD  components  is  contained  in  DOD 
Directive  5000.1,  Major  System  Acquisition.  This  directive  does  not  attempt  to  foresee  all 
of  the  problems  which  might  be  encountered  and  thus  provide  a  solution.  Rather,  it 
enunciates  guidance  the  Secretary  of  Defense  expects  program  managers  to  follow.  For 
example,  note  the  following  excerpts  from  the  directive: 
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A  streamlined  acquisition  organization  .  .  .  will  be  used.  .  .  . 

Military  requirements  for  new  acquisitions  must  be  thoroughly  reviewed.  During 
this  process,  trade-offs  must  be  made  among  performance  requirements,  cost,  and 
schedule. 

Develop  acquisition  strategies  at  the  inception  of  each  acquisition  that  sets  forth 
the  objectives,  resources,  management  assumptions,  prototyping  plan  ,  extent  of  competi¬ 
tion,  procurement  approach,  .  .  . 

Assign  to  the  program  manager  authority  and  resources  commensurate  with  the 
responsibility  and  accountability  for  executing  the  program  efficiently. 

As  the  above  sentences  illustrate,  DOD  Directive  5000.1  is  no  cookbook  to  which  a 
PM  need  refer  daily.  The  idea  is  to  pick  good  people,  tell  them  their  job,  and  then  let 
them  do  it.  That  seems  to  be  a  workable  philosophy  within  which  motivated  people  can 
exercise  the  management  skills  they  have  developed,  and  feel  free  to  innovate  when  the 
opportunity  presents  itself. 

SECTION  III 

THE  OPERATIONAL  REQUIREMENTS  PROCESS 

The  operational  requirements  process  provides  the  means  to  identify  operational 
deficiencies,  state  operational  needs  and  initiate  development  or  improvement  of  systems 
or  equipment.  The  various  Defense  Mission  Areas  or  specific  missions  for  which  the  Air 
Force  is  responsible  are  delegated  to  the  major  commands.  The  Air  Force  looks  to  the 
major  commands  to  continuously  analyze  their  mission  capabilities  and  identify  opera¬ 
tional  needs.  Operational  needs  may  result  from  a  projected  deficiency  or  obsolescence  in 
existing  systems,  a  technological  opportunity,  or  an  opportunity  to  reduce  cost.  The 
basic  principle  of  the  AF  operational  requirements  process,  as  defined  by  AFR  57-1, 
Operational  Needs,  is  to  encourage  and  draw  upon  the  ideas  and  judgment  of  experienced 
field  personnel.  This  is  accomplished  via  the  coordination  and  publication  of  a  State¬ 
ment  of  Operational  Need  (SON). 

Prerequisite  to  the  identification/documentation  of  operational  needs  is  a 
comprehensive  mission  analysis.  This  analysis  must  examine  the  basic  mission  tasks  and 
assess  the  command’s  ability  to  perform  each  task  in  terms  of  current  and  projected 
capability,  the  present  and  projected  threat,  the  operational  environment,  and  any  other 
constraints  which  may  limit  solutions  to  identified  needs. 

The  reader  should  recognize  that  system  developments  or  improvements  also  result 
from  recognition  that  a  technological  advancement  may  have  mission  applications.  The 
scientific  community,  within  the  government  and  throughout  the  defense  contractor 
world,  remains  alert  to  potential  applications  of  discoveries,  and  constitutes  an  impor¬ 
tant  source  of  possible  solutions  to  deficiencies  and  operational  enhancements  through 
technological  opportunities. 

Operational  needs,  identified  by  the  analysis  process,  which  cannot  be  satisfied 
within  the  command’s  existing  capabilities  and  which  will  likely  lead  to  system  or  equip¬ 
ment  development,  should  be  considered  for  processing  as  a  SON.  The  originator  of  a 
SON  can  obtain  assistance  from  the  Air  Force  Systems  Command  ( AFSC ),  Air  Force 
Logistics  Command  ( AFLC ),  and  Air  Training  Command  ( ATC)  in  conducting  mission 
analyses  and  preparing  SONs.  SONs  may  be  submitted  by  any  major  command  or  higher 
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echelon  of  the  Air  Force. 

Prior  to  publishing  a  SON,  the  originator  is  expected  to  coordinate  it  in  accordance 
with  a  comprehensive  list  directed  by  AFR  57-1.  AFSC,  AFLC  and  ATC  will  review 
draft  SONs  and  provide  information  to  the  originator  concerning  the  technology  base, 
integrated  logistics  support,  life  cycle  cost,  and  safety  and  training  considerations  to  the 
extent  that  information  on  solutions  allows.  In  the  event  another  major  command 
( MAJCOM)  proposes  to  use  the  end  product  likely  to  be  developed,  that  command  must 
offer  co-sponsorship  of  the  SON  and  provide  the  originator  with  justification  based  on  its 
assigned  mission 

In  preparing  a  SON  which  documents  a  need,  the  originating  command  must  iden¬ 
tify  the  proposed  implementing  command  --  normally  AFSC.  The  implementing  will 
have  program  management  responsibility  if  it  is  decided  that  action  will  be  taken  to 
develop  concepts  to  satisfy  that  need  and  that  a  system  development  will  likely  occur. 

Since  a  major  factor  in  the  evaluation  of  anv  proposed  investment  must  be  the 
expected  cost,  a  draft  Program  Decision  Package  ( PDP )  must  accompany  the  SON. 
That  PDP  must  identify  the  funds  necessary  to  begin  concept  definition  and  provide  a 
preliminary  estimate  of  the  program  funds  required  to  pursue  the  most  likely  solution  to 
the  stated  need. 

Now  the  SON  faces  the  HQ  USAF  validation  process  (See  Figure  4).  This  is  accom¬ 
plished  through  a  corporate  review  of  the  stated  need  and  supporting  justification, 
within  the  context  of  total  Air  Force  requirements,  objectives,  mission,  and  priorities, 
and  in  consideration  of  resources  limitation.  Validation  of  the  stated  need  by  the 
appropriate  authority  constitutes  the  Mission  Need  Determination/Program  Initiation 
decision  point  of  the  acquisition  process.  The  appropriate  authority  is  determined  predi¬ 
cated  upon  such  factors  as  the  estimated  cost,  impact  on  DOD /Allied  operational  capa¬ 
bility,  international  involvement,  political  sensitivity,  and  multiple  service  involvement. 
Furthermore,  the  level  of  review  and  approval  required  to  initiate  an  acquisition  program 
will  determine  the  nature  of  the  documentation  required  to  support  such  a  decision. 

Additional  documentation,  if  required  to  support  higher  level  decisions,  is  prepared 
and  submitted  by  the  Air  Staff. 

The  Secretary  of  Defense  designates  those  systems  which  are  to  be  managed  as 
major  systems.  That  decision  may  be  based  upon  one  or  more  of  the  following  factors: 

--Development  risk,  urgency  of  need,  or  other  items  of  interest  to  the  SEC- 
DEF. 

—Joint  acquisition  of  a  system  by  the  DOD  and  representative  of  another 
nation  or  by  two  or  more  DOD  Components. 

—The  estimated  requirement  for  research,  development,  test  and  evaluation 
(RDT&E),  and/or  procurement  funds.  The  nominal  funds  threshholds  for 
major  systems  are:  RDT&E-$200  million,  procurement-$l  billion  (FY  80  dol¬ 
lars). 

—The  estimated  requirement  for  manpower  to  operate,  maintain,  and  support 
the  system  in  the  field. 
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Figure  4 

—Congressional  interest. 

The  initial  need  determination  for  major  system  acquisitions  is  made  in  the  plan¬ 
ning,  programming  and  budgeting  system  ( PPBS )  based  upon  an  evaluation  of  a  Mission 
Need  Statement  ( MNS ).  An  MNS  is  required  for  all  proposed  acquisitions  for  which  the 
service  estimates  costs  will  exceed  $100  million  (FY  80  dollars)  in  research,  development, 
test  and  evaluation,  and/or  $500  million  (FY  80  dollars)  in  procurement  funds.  The 
MNS  is  included  as  an  attachment  to  the  service’s  Program  Objective  Memorandum, 
and  inclusion  of  the  system  new  start  in  the  DOD  budget  authorizes  the  service  to 
proceed  with  concept  definition.  This  authorization  may  lead  to  a  major  system  develop¬ 
ment  or  to  an  Air  Force  Designated  Acquisition  Program  ( AFDAP ).  The  beginning  of 
the  concept  definition  effort  does  not  depend  upon  the  completion  of  Congressional  action 
on  the  DOD  budget.  Exploratory  or  advanced  development  funds  are  usually  available 
for  use  at  the  discretion  of  the  service  Secretary  and  may  be  provided  for  the  initial 
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conceptual  effort. 

Air  Force  Designated  Acquisition  Programs  are  potentially  critical  programs  (but 
not  selected  as  major  programs)  which  the  Secretary  of  the  Air  Force  has  decided  war¬ 
rant  his  attention  at  the  program  decision  milestones.  That  decision  will  be  based  upon 
an  assessment  of  the  following  criteria: 

—Potential  resource  consumption 

—Significant  impact  on  Air  Force  Capability. 

—Technology  advancement. 

—Other  service(s)  involvement. 

—Political  sensitivity. 

For  AFDAP  programs  the  Secretary  of  the  Air  Force  will  be  the  decision  maker  at 
all  of  the  program  milestones.  Potential  AFDAP  programs  require  a  MNS  to  be  submit¬ 
ted  with  the  service’s  POM. 

Potential  acquisition  programs  which  do  not  meet  the  above  criteria,  but  which  are 
expected  to  exceed  $15  million  RDT&E  costs  or  $75  million  total  costs  (RDT&E  plus 
production)  will  be  approved  at  the  Air  Staff  level.  The  discussion  which  follows  will 
describe  the  acquisition  process  as  it  applies  to  major  system  acquisition  programs;  how¬ 
ever,  the  process  is  similar  for  AFDAP  and  other  less  than  major  programs;  the  primary 
difference  is  the  level  of  review  and  approval. 

Following  MNS  approval  and  a  SecAF  decision  to  begin  concept  exploration,  HQ 
USAF  provides  formal  direction  to  the  implementing  and  participating  commands  by 
using  a  Program  Management  Directive  ( PMD ).  The  PMD  is  used  during  the  entire 
acquisition  life  cycle  to  approve,  transfer,  modify,  or  terminate  programs. 

SECTION  IV 

THE  CONCEPT  DEFINITION  PHASE 

At  this  point  there  is  a  commitment  only  to  identify  and  explore  alternative  solu¬ 
tions.  This  initial  approval  and  establishment  of  a  system  acquisition  program  does  not 
automatically  mean  that  a  new  system  will  be  acquired.  With  an  approved  need,  other 
means  of  satisfying  the  need  must  be  analyzed  along  with  the  exploration  of  alternative 
system  solutions.  For  example:  the  mission  need  may  be  best  satisfied  by  a  change  in 
doctrine,  by  deployment  of  additional  personnel,  by  increased  training,  by  modifications 
to  existing  equipment,  by  off-the-shelf  procurement  of  a  foreign  or  domestic  system 
already  in  production,  or  by  a  new  system  acquisition  effort. 

The  initial  PMD  for  a  program  formally  implements  the  Mission  Need  Determina- 
tion  Decision.  An  important  element  of  the  PMD  which  directs  the  conceptual  phase 
effort  is  the  assignment  of  the  PM  and  the  inclusion  of  a  charter  stating  his  responsibil¬ 
ity,  authority  and  accountability  for  achieving  program  objectives.  The  selection  of  the 
PM  will  usually  involve  key  personnel  in  the  Air  Staff  as  well  as  the  Commander  of 
AFSC  and  his  key  advisors.  At  this  time  AFLC  will  normally  name  a  senior  logistician 
to  become  a  part  of  the  program  office  ( PO )  as  the  Deputy  Program  Manager  for  Logis¬ 
tics  {DPMI). 

It  is  incumbent  upon  the  new  program  manager  to  develop  an  acquisition  strategy 
tailored  to  his  particular  program.  It  should  address  the  technical,  business  and 
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management  aspects  of  the  program  and  provide  a  basis  for  the  integration  of  these 
areas  in  achieving  program  objectives.  Initially,  the  strategy  may  be  limited  in  content, 
but  it  should  be  expanded  and  refined  as  the  program  progresses.  This  effort  must  be 
closely  coordinated  with  AFLC,  ATC  and  the  potential  using  command  if  it  is  to  result 
in  a  well-ordered,  soundly  conceived  program.  The  acquisition  strategy  which  results 
from  the  coordination  effort  could  typically  include:  Use  of  the  contracting  process, 
essential  achievement  milestones,  development  of  test  and  evaluation  criteria,  decisions 
on  whom  to  solicit  and  content  of  solicitations,  guidelines  for  the  acceptance  or  rejection 
of  proposals,  and  methods  for  appropriate  tradeoffs  among  investment  costs,  ownership 
costs,  schedules,  and  performance  characteristics. 

Business  planning  for  the  concept  definition  phase  is  a  subset  of  the  acquisition 
strategy  and  should  emphasize  competitive  exploration  of  alternatives.  Consequently,  a 
solicitation  for  proposed  solutions,  in  terms  of  mission  need  and  not  of  explicit  system 
characteristics,  is  a  key  action  for  this  phase. 

The  vehicle  for  shaping  the  contracting  process  is  the  Request  For  Proposal 
(RFP).  The  RFP  is  the  official  document  for  soliciting  effort  from  potential  sources,  and 
it  is  important  that  it  be  structured  to  support  the  strategy  developed  for  acquiring  the 
system.  In  the  concept  definition  phase,  it  is  structured  to  encourage  responses  from  a 
broad  range  of  qualified  firms  and  the  academic  community,  and  also  to  emphasize  inno¬ 
vation  and  competition.  Therefore,  an  RFP  for  a  system  design  concept  should  provide 
complete  information  concerning  the  mission  need  or  task,  the  operating  environment 
including  threat,  schedule  and  cost  goals,  and  capability  objectives,.  Each  offeror  is  then 
free  to  propose  his  own  technical  approach,  main  design  features,  and  alternatives  so 
that  the  Government  may  achieve  the  benefits  of  innovation  and  competition.  Offerors 
should  not  be  constrained  by  preordained  or  prematurely  selected  solutions. 

Federal  laboratories,  federally  funded  research  and  development  centers,  and  other 
not-for-profit  organizations  are  also  sources  for  system  design  concepts.  Ideas,  concepts, 
or  technology  developed  at  government  expense  may  be  made  available  to  private  indus¬ 
try,  and  industry  may  incorporate  that  information  in  their  proposed  alternatives.  Each 
of  the  alternatives  must  be  defined  in  sufficient  conceptual  detail  so  that  the  basic  alter¬ 
native  solutions  can  be  considered  in  terms  of  technical,  support,  operations,  and  mainte¬ 
nance  concepts,  as  well  as  the  relative  life  cycle  costs. 

Each  alternative  must  be  evaluated  and  the  best  selected.  In  addition  to  paper  ana¬ 
lyses  and  studies,  limited  experiments  and  tests  may  be  conducted  during  this  phase  to 
determine  the  technical  feasibility  of  concepts,  defined  subsystems,  and  key  components. 
Even  at  this  early  stage,  cost  estimates  must  be  made  for  each  concept.  There  must  also 
be  an  assessment  to  assure  that  the  solutions  proposed  will  likely  be  able  to  counter  the 
defined  threat.  There  would  certainly  need  to  be  some  study  to  assess  how  long  until 
each  alternative  might  be  ready  for  operational  use. 

During  the  uncertain  period  of  identifying  and  exploring  concepts,  contracts  which 
are  negotiated  will  typically  cover  relatively  short  time  periods  at  fixed  dollar  levels. 
Timely  technical  reviews  will  be  made  to  effect  the  orderly  elimination  of  the  least  attrac¬ 
tive  design  concepts.  Selection  of  the  concepts  offering  the  best  potential  balance  of  cost, 
schedule  ami  technical  performance  will  he  made  by  a  team  led  by  the  PM.  In  addition, 
the  use  of  consultants  from  outside  the  Air  Force  is  encouraged  to  help  lend  objectivity 
and  to  add  required  technical  expertise.  The  major  products  of  the  program  office  during 
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this  phase  will  be  the  planning  and  management  documentation  required  to  support  the 
program  review  and  decision  processes  prerequisite  to  entering  the  Demonstration  and 
Validation  phase. 

When  the  competitive  exploration  of  alternative  system  concepts  has  been  com¬ 
pleted  to  the  point  where  the  selected  alternative(s)  warrant  system  demonstration,  the 
Secretary  of  the  Air  Force  will  request  SECDEF  approval  (Milestone  I,  Requirement  Vali¬ 
dation  Decision)  to  enter  into  the  Demonstration  and  Validation  phase.  This  recommen¬ 
dation  is  documented  in  the  System  Concept  Paper. 

The  System  Concept  Paper  ( SCP )  is  reviewed  by  the  Air  Force  System  Acquisition 
Review  Council  ( AFSARC )  followed  by  the  Defense  Acquisition  Board  (DAB)  prior  to 
the  SECDEF  decision.  That  process  will  be  discussed  in  the  next  section. 

SECTION  V 

DAB/ APS  ARC  REVIEW  PROCESS 

The  results  of  the  conceptual  phase  efforts  are  documented  in  a  System  Concept 
Paper  (SCP).  The  SCP  is  prepared  by  the  program  manager  and  contains  an  evaluation 
of  the  results  of  the  conceptual  effort  as  well  as  recommendations  for  a  continued  acquisi¬ 
tion  strategy  tailored  to  program  needs  and  goals.  As  a  result  of  the  studies/analyses  of 
design  concepts  and  alternative  potential  solutions,  the  SCP  should  express  expected  sup¬ 
port  and  operational  capabilities  and  broad  cost,  operability  and  performance  goals.  The 
SCP  provides  the  primary  documentation  for  use  by  the  DAB  in  arriving  at  a  Milestone 
I  recommendation.  The  Milestone  I  decision  is  a  SECDEF  validation  of  the  requirement 
based  upon  an  evaluation  of  concepts,  costs,  and  schedule.  In  the  SCP,  the  program 
manger  will  recommend  the  nature  and  timing  of  the  next  SECDEF  decision  point,  Mile¬ 
stone  II,  so  that  a  decision  to  proceed  will  establish  the  objectives  and  goals  for  the  next 
life  cycle  phase. 

The  reader  should  recognize  that  this  milestone  decision  period  should  not  put  the 
program  on  hold  and  result  in  a  work  stoppage  while  the  review  and  decision  process 
takes  place.  The  PM  may  not,  in  fact  probably  will  not,  have  a  complete  package  or 
final  conceptual  studies  to  present  at  Milestone  I.  There  will  likely  be  conceptual  studies 
and  analyses  still  in  progress.  Milestone  I  should  be  scheduled  when  there  is  sufficient 
information  and  evidence  to  support  a  recommendation  either  that  the  program  proceed 
into  the  next  phase  of  the  life  cycle  with  a  demonstration/validation  of  one  or  more  pro¬ 
posed  solutions  or  that  the  program  be  discontinued. 

If  a  decision  to  proceed  is  made,  the  PM  should  conclude  any  studies  still  in  pro¬ 
gress  and  move  rapidly  into  the  demonstration/validation  phase.  If  the  decision  is  to 
discontinue  the  program,  the  PM  should  terminate  his  conceptual  studies  to  minimize 
costs. 

The  DAB  (see  Figure  5)  serves  as  an  advisory  body  to  the  SECDEF  for  major  sys¬ 
tem  acquisitions  and  provides  supporting  information  and  recommendations  when  deci¬ 
sions  are  necessary.  The  DAB  has  the  responsibility  to  review  such  major  system  acquisi¬ 
tion  issues  as  the  Defense  Acquisition  Executive  (DAE)  determines  to  be  necessary.  The 
DAE  is  the  principal  official  to  whom  the  SECDEF  looks  for  the  development  and  imple¬ 
mentation  of  acquisition  policy  and  for  advice  during  the  acquisition  decision  process.  He 
is  the  chairman  of  and  spokesman  for  the  DAB.  Following  each  milestone  review,  the 
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DAB  will  usually  recommend  that  the  SECDEF  either  (1)  approve  the  next  phase,  (2) 
order  the  Air  Force  to  conduct  further  studies,  or  (3)  discontinue  the  program.  In  addi¬ 
tion,  the  DAB  may  be  convened  at  any  time  to  review  a  program  that  has  encountered 
significant  problems  which  indicate  the  SECDEF  should  review  its  status.  DAB  reviews 
are  a  means  to  evaluate  information  necessary  to  the  SECDEF  for  decisions  specifically 
reserved  to  him.  They  are  not  to  be  used  to  request  data  other  than  those  required  for 
these  decisions. 

DEFENSE  ACQUISITION  BOARD  (DAB) 

CHAIRMAN: 

USD  (ACQUISITION)  (DEFENSE  ACQUISITION 
EXECUTIVE) 

MEMBERS: 

VICE-CHAIRMAN,  JCS 
ASD  (C) 

ASD  (P&L) 

DIRECTOR  (OT&E) 

DIRECTOR  (PO) 

SERVICE  ACQUISITION  EXECUTIVE 
PRINCIPAL  DEPUTY  To  USD  (A) 

DIRECTOR  (Appropriate  Committee) 

Figure  5. 

The  decision  reached  at  each  of  the  review  points  includes  a  description  of  the  sys¬ 
tem  in  terms  of  its  expected  capabilities;  specific  cost,  schedule,  and  performance  goals  to 
be  accomplished  during  the  next  life  cycle  phase;  general  acquisition  strategy;  and  any 
other  factors  the  DAE  considers  critical  to  the  program’s  success.  This  description 
becomes  a  formal  agreement  —  almost  a  contract  --  between  the  DAE  and  the  PM,  which 
may  only  be  changed  with  the  DAE’s  concurrence.  The  contract  is  formally  known  as 
the  Program  Baseline. 

The  AFSARC  was  first  chartered  in  June  1976  by  the  Secretary  of  the  Air  Force  in 
accordance  with  DOD  Directive  5000.1  and  is  similar  in  composition,  responsibilities  and 
operation  to  the  DAB  (see  Air  Force  Regulation  800-2).  Its  purpose  is  to  serve  as  an 
advisory  body  to  the  Secretary  of  the  Air  Force  and  through  him  to  the  SECDEF  on 
major  system  acquisitions  and  to  provide  information  and  recommendations  in  support 
of  decisions  as  necessary.  The  AFSARC  reports  to  the  Secretary  of  the  Air  Force.  Occa¬ 
sionally  the  Defense  Acquisition  Executive  may  decide  that  the  AFSARC  review  and 
findings  are  sufficient  and  waive  the  DAB  review  for  a  major  system.  For  Air  Force 
Designated  Acquisition  Programs  ( AFDAP )  the  Secretary  of  the  Air  Force  decision  will 
establish  the  approved  program  and  authorize  beginning  the  subsequent  phase  of  the 
acquisition  life  cycle. 
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The  AFSARC  reviews  all  major  system  acquisition  programs  at  Milestones  1,  II,  III, 
IV,  and  V.  (see  Figure  3  [See  above]).  Formal  DAB  reviews  are  also  normally  held  at 
Milestones  I,  II,  III,  IV,  and  V.  In  addition,  any  DOD  component  head  or  DAB  member 
may  request  the  DAE,  at  any  point  in  the  acquisition  process,  to  schedule  a  DAB  meet¬ 
ing  to  consider  significant  issues.. 

If  the  DAB  and/or  AFSARC  (when  a  DAB  review  is  not  required)  conclude  that 
the  review  does  describe  a  prospective  system  for  which  a  true  mission  need  exists  and 
for  which  the  technical,  military,  and  economic  bases  can  be  sufficiently  well  established, 
they  will  recommend  that  the  SECDEF  approve  the  transition  of  the  program  to  the 
next  phase.  If  the  SECDEF  concurs  with  the  recommendation,  he  will  approve  the  SCP 
and  issue  an  Acquisition  Decision  Memorandum  (.4DA/),  thus  reaffirming  the  mission 
need  and  approving  one  or  more  selected  alternatives  for  competitive 
demonstration  /  validation. 

The  ADM  documents  the  SECDEF's  milestone  decision  including  approval  of  goals 
and  thresholds  for  cost,  schedule,  performance  and  supportability  against  which  the  pro¬ 
gram  must  be  managed  and  will  be  evaluated.  At  each  milestone  additional  threshold 
values  are  established  and  documented  to  reflect  allowable  variances  from  the  approved 
point  estimates.  Since  such  thresholds  represent  operating  limitations  for  the  program 
manger,  any  time  they  are  exceeded,  or  are  expected  to  be  exceeded,  the  program  will 
normally  be  subject  to  review. 

SECTION  VI 

THE  DEMONSTRATION  AND  VALIDATION  PHASE 

Subsequent  to  SECDEF  approval  to  proceed  with  the  demonstration/validation 
effort  and  upon  receipt  of  the  ADM,  a  revised  PMI)  is  prepared  by  HQ  USAF  to: 
transmit  the  "go  ahead"  to  the  implementing  command,  normally  AFSC;  enumerate  the 
roles  of  the  participating  organizations;  identify  resources;  specify  constraints;  and  del¬ 
ineate  required  tasks.  With  the  PMD  in  hand,  AFSC  will  augment  the  SPO  as  neces¬ 
sary/  practical  and  commence  the  Demonstration  and  Validation  phase. 

In  the  Demonstration  and  Validation  phase,  definitization  of  the  selected 
alternative(s)  is  expanded,  and  the  value  and  practicality  of  the  increasingly  specific 
design  approach  continues  to  be  checked.  The  definitization  work  is  typically  carried  out 
in  one  of  three  ways:  (1)  primary  system  hardware  prototyping,  (2)  paper  studies,  or  (3) 
paper  definition  plus  subsystem  prototyping.  Whichever  way  is  chosen,  the  central 
thrust  of  the  effort  during  this  phase  is  the  reduction  of  technical  risk  and  economic 
uncertainty  through  a  more  detailed  definition  of  the  new  system.  This  definitization 
work  is  commonly  done  by  defense  contractors  under  SPO  direction. 

The  approach  to  the  demonstration/validation  effort  currently  preferred  is  to  select 
at  least  two  contractors  to  build  prototypes  which  are  to  be  evaluated  during  the  latter 
days  of  this  phase.  There  are  at  least  two  major  payoffs  in  this  dual  contractor 
approach.  One  is  that  we  can  maintain  competition  longer  in  the  acquisition  --  which 
tends  to  supply  a  better  product  at  the  best  price.  The  other  is  that  we  have  a  much 
better  data  base  for  our  development  decision  after  seeing  and  evaluating  alternate 
design  approaches  as  they  are  translated  into  hardware. 
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It  should  be  noted  that  the  prototype  approach  to  demonstration /validation  is  con¬ 
cerned  with  fabrication  of  a  system  resembling  the  operational  system  only  to  the  extent 
that  performance  objectives  can  be  validated. 

The  paper  studies  approach  to  demonstration/validation  emphasizes  the  competi¬ 
tion  of  two  or  more  defense  contractors,  utilizing  studies  and  analyses,  in  an  attempt  to 
define  and  refine  the  system.  The  decision  as  to  which  contractors)  will  receive  awards 
for  full-scale  development  will  depend  upon  caret ul,  detailed  evaluation  of  the  competing 
proposals. 

The  selection  of  the  most  practical  approach  must  be  based  upon  risks,  tradeoffs, 
availability  of  competition,  and  program  resources.  For  some  very  large,  sophisticated 
systems  the  cost  of  the  full  prototype  approach  to  demonstration/ validation  could  he 
prohibitive.  A  compromise  solution  may  be  to  select  a  prime  contractor  based  upon  a 
rigorous  source  selection  evaluation  of  competitive  designs,  and  then  prototype  those  sub¬ 
systems  which  are  expected  to  offer  the  greatest  technical  risk. 

The  total  effort  of  the  Demonstration  and  Validation  Phase  is  evaluated  in  prepara¬ 
tion  for  the  Milestone  II.  Program  Mo-Ahead  Decision  as  once  again  the  program  enters 
the  AFSARC/DAJ3  process.  Primary  program  review  documents  are  now  the  Decision 
Coordinating  Paper  and  the  Integrated  Program  Summary  (DCP  and  IPS).  The  DCP 
and  IPS  summarize  the  Air  Force  acquisition  plan  for  tiie  system's  life-cycle  and  provide 
a  management  overview  of  the  program.  They  will  include  essential  program  informa¬ 
tion  such  as:  need /threat,  design  concept,  supportabilitv,  operability,  issues  and  risks, 
and  affordability  in  terms  of  project. -d  budget  and  phasing  of  out-year  funding.  The 
DCP  is  an  18-page  document  which  is  oriented  primarily  to  a  summarization  of  program 
progress  to  date  and  the  plan  lor  accomplishing  the  next  life-cycle  phase.  The  IPS  is  a 
30  page  paper  which  takes  a  broader  view  to  include  progress  toward  ensuring  an  opera¬ 
tional  capability  and  the  planning  for  support  and  organizational  factors.  The  AFSARC 
and  DAB  review  the  program  to  ensure  that  t he  need  still  exists,  and  that  procurement 
methods,  contract  form,  management  systems,  etc.,  match  the  job  to  be  done,  its  goals, 
risks  and  uncertainties.  Their  recommendation  to  the  Secretary  of  the  Air  Force  and 
Secretary  of  Defense  depends  heavily  upon  their  evaluation  of  how  well  the  Air  Force  has 
defined  the  technical,  financial,  and  schedule  factors  of  the  program.  The  results  of  the 
Milestone  II  review  will  be  transmitted  to  the  Air  Force  by  an  Acquisition  Decision 
Memorandum.  This  decision,  in  addition  to  being  a  commitment  to  continue  the  pro¬ 
gram  through  engineering  development,  includes  a  commitment  to  acquire  long-lead  pro¬ 
curement  items  and  to  perform  low  rate  in'tial  production  {UUP)  to  support  initial 
operational  testing.  It  should  occur  when  there  is  sufficient  evidence  to  support  a  deci¬ 
sion  that  a  satisfactory  solution  has  been  demonstrated  and  validated.  This  does  not 
assume  that  there  are  no  risks  or  uncertainties  remaining.  There  should,  however,  be  a 
high  level  of  confidence  r hat  the  remaining  technical,  cost,  and  schedule  risks  have  been 
identified  and  that  they  can  be  resolved  within  program  resource  and  time  constraints. 
If  the  decision  is  to  continue,  the  program  will  enter  Full-Scale  Development/Low  Rate 
Initial  Production. 
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SECTION  VII 

THE  FULL-SCALE  DEVELOPMENT/LOW  RATE  INITIAL  PRODUCTION  PHASE 


Following  the  milestone  11  decision,  quarterly  program  renews  are  conducted  by  the 
Secretary  of  the  Air  Force  and  key  program  issues  reported  to  the  SECDEF  and  the 
Defense  Acquisition  Executive. 

During  this  phase  (the  third  of  the  life  cycle),  the  system,  including  all  essential 
support  equipment  and  documentation,  is  designed,  developed,  fabricated,  and  tested. 
The  intended  output  is  a  pre-production  prototype  and  includes  the  documentation 
needed  to  produce  the  system  for  the  operational  inventory.  To  accomplish  this.  it.  is 
necessary  to  complete  the  engineering  design  and  demonstrate  the  adequacy  of  the  design 
via  a  formalized  and  comprehensive  full  system  test  effort. 

By  the  end  of  this  phase,  detailed  design  specifications  will  be  finalized  and 
engineering  drawings  prepared  which  become  the  basis  for  buying  force  structure  quanti¬ 
ties  of  system  units  during  the  production  phase.  The  fabrication  of  developmental 
hardware  is  a  major  effort  during  t his  phase.  In  support  of  that  effort,  the  proposed 
design  is  examined  in  great  detail  during  preliminary  design  reviews.  Before  hardware 
fabrication  is  authorized,  the  Program  OBi ce  and  support  personnel  become  involved  in 
review(s)  of  mockups  for  the  proposed  equipment  to  assure  that  the  configurations  are  in 
accordance  with  the  initial  design  requirements.  Finally,  critical  design  review(s)  is  (are) 
held,  which  is  the  last  official  chance  to  comment  on  the  developing  design  befon  com¬ 
mitment  to  accept  that  design. 

Testing  is  a  vital  Ingredient  in  a  successful  FSD  program.  It  is  through  test  and 
evaluation,  conducted  by  the  contractors  and  by  the  Air  Force,  that  the  technical  and 
engineering  problems  that  need  to  be  solved  are  identified  and  the  resulting  design  fixes 
demonstrated.  System  testing  starts  with  the  development  of  early  plans  for  testing  the 
components  in  the  system.  The  impact  of  various  aspects  of  testing  becomes  increasingly 
significant  as  each  configuration  item  (Cl)  proceeds  through  development  testing.  The 
testing  process  reaches  a  high  degree  of  detail  in  subsystem  testing  and  finally  full  system 
testing  which  includes  the  support  elements  of  the  system. 

The  primary  purpose  of  test  and  evaluation  ( T&E )  during  the  acquisition  process  is 
the  reduction  of  risk,  either  the  risk  that  the  system  or  equipment  will  not  meet  perfor¬ 
mance  specifications  or  the  rise  that  the  system  or  equipment  cannot  be  effectively 
employed  in  its  intended  operational  environment.  Furthermore,  T&F  is  the  primary 
means  by  which  achievement  of  program  objectives  is  demonstrated  to  justify  continuing 
or  increasing  the  commitment  of  resources  to  acquisition  programs. 

There  are  basically  two  types  of  testing  associated  with  acquisition  programs: 
Development  Test  and  Evaluation  ( DT&E )  and  Operational  Test  and  Evaluation 
(O'l'&E).  OT&E,  in  the  USAF  environment,  is  further  differentiated  by  identifying 
OT&E  accomplished  prior  to  the  Milestone  III  /Production  Decision  as  Initial  Operational 
Test,  and  Evaluation  ( IOT&E ).  (See  Figure  t»). 


'Hie  purpose  of  DT&E  is  to: 

—Demonstrate  that  engineering  design  and  development 


are  complete. 
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—Minimize  design  risk, 

—Demonstrate  that  the  system  or  equipment  meets  specifications,  and 

—Verify  that  proposed  design  changes  do  not  degrade  overall  system 
performance. 

DT&E  is  essentially  a  detailed  engineering  analysis  of  system  performance  when  design 
of  the  system  is  tested  and  evaluated  against  engineering  and  performance  criteria  (nor¬ 
mally  derived  from  the  system  specification)  by  the  implementing  command. 

OT&E  is  conducted  to: 

—Estimate  military  utility,  operational  effectiveness  and  suitability, 

—Provide  feedback  prior  to  key  milestone  decisions, 

—Demonstrate  that  the  system  can  be  supported  logistieally  in  a  deployment 
status. 
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--Identify  new  uses  for  the  system,  and 
--Reshape  tactics, 

OT&E  is  essentially  an  operational  assessment  during  which  the  system  is 
evaluated  against  operational  criteria  by  personnel  with  the  same  qualifications  as  those 
who  will  eventually  operate,  maintain,  and  support  the  system  when  it  is  deployed.  The 
role  of  T&E  is  stated  in  D0D1  5000.3  as  follows: 

Test  and  evaluation  shall  begin  as  early  as  possible  and  be  conducted  throughout 
the  system  acquisition  process  to  assess  and  reduce  acquisition  risks  and  to  esti¬ 
mate  the  operational  effectiveness  and  operational  suitability  of  the  system  being 
developed  .  .  .  Successful  accomplishment  of  T&E  objectives  will  he  a  key 
requirement  for  decisions  to  commit  significant  additional  resources  to  a  pro¬ 
gram  or  to  advance  it  from  one  acquisition  phase  to  another 

Frequently  the  desire  to  maintain  program  continuity  and  pressure  to  meet  esta¬ 
blished  initial  operational  capability  commitments  dictate  a  decision  to  begin  a  low  rate 
initial  production  program  before  the  full  demonstration  of  design  stability.  This  over¬ 
lapping  of  the  FSD  and  production  phases,  called  concurrency,  involves  the  acceptance  of 
certain  risks.  Since  system  testing  will  not  have  been  completed  before  the  low  rate  pro¬ 
duction  process  begins,  there  will  almost  certainly  be  test  failures  which  may  lead  to 
design  revisions  and  the  necessity  to  incorporate  changes  in  the  production  process  or  in 
delivered  prime  mission  equipment.  The  effect  of  those  changes  may  ripple  across  sup¬ 
port  equipment,  data,  simulators,  training  programs,  etc.  On  the  other  hand,  the  more 
closely  items  for  initial  operational  testing  resemble  the  final  production  configuration, 
the  sooner  a  stable  production  process  can  be  established.  Clearly  decisions  as  to  how 
much  concurrency  to  incorporate  into  the  acquisition  strategy  must  be  made  carefully  so 
that  the  expected  benefits  outweigh  the  potential  risks.  The  more  mature  the  system 
technology  and  the  more  stable  the  design  the  less  hazardous  is  a  decision  to  use  con¬ 
currency.  Current  policy  requires  a  Low  Rate  Initial  Production  Report  be  provided  to 
the  Secretary  of  Defense,  and  the  Congress  before  the  ADM  is  signed  to  authorize  Full 
Rate  Production/Deployment.  The  LRIP  Report  is  an  assessment  of  the  adequacy  of  the 
test  results  and  of  the  effectiveness  and  suitability  of  the  system  for  combat. 

Milestone  III  approval  by  the  SECDEF  constitutes  the  production/deployment  deci¬ 
sion,  which  is  documented  in  an  ADM  and  implemented  by  a  revision  to  the  PMD.  That 
decision  to  produce  for  operational  use  defines  the  initial  quantity  to  be  produced,  and 
approves  plans  for  future  production  and  deployment.  If  no  significant  changes  have 
occurred  affecting  the  system  during  the  FSD/LR1P  phase  (i.e.,  major  design  change, 
large  increase  in  costs,  change  in  contractual  approach,  etc.)  the  decision  for  production 
may  be  delegated  to  the  individual  service  secretary. 

SECTION  VIII 

THE  PRODUCTION /DEPLOYMENT  AND  OPERATIONS  SUPPORT  PHASES 

The  actual  commitment  to  production  is  formally  and  contractually  accomplished 
at  the  onset  of  the  Production  Phase.  During  this  phase,  the  system,  including  training 
equipment,  spares,  facilities,  etc.,  is  produced  for  operational  use.  All  verification  of 
hardware  compliance  with  final  specification  requirements  is  usually  completed  no  later 
than  this  phase.  Any  decisions  deferred  from  FSD/LRIP  regarding  support  areas  such  as 


maintenance,  logistic  support,  and  training  must  now  be  settled.  Production  manage¬ 
ment  systems  for  control  of  the  factors  of  production,  quality  and  finished  product  inven¬ 
tory  are  applied. 

Tests  begun  during  FSD/LR1P  are  continued  during  the  Production/Deploymon! 
Phase.  System  elements  arc  integrated  into  a  complete  system  in  as  near  an  operational 
configuration  as  possible.  Contractor  participation  in  testing  is  not  complete  until  sys¬ 
tem  performance  specification  requirements  are  met. 

It  is  also  during  this  phase  that  program  management  responsibility  transfer 
(. PMRT )  occurs.  PMRT  is  the  formal  act  of  transferring  program  management  responsi¬ 
bility  for  a  system  or  equipment  from  Ah  SC  to  AFLC.  PMRT  includes  transfer  of 
engineering  responsibilities.  The  date  for  PMRT  is  determined  by  negotiations  between 
the  implementing  and  supporting  commands  during  the  FSD/LR1P  Phase  and  forwarded 
to  HQ  USAF  for  inclusion  in  the  production  PMD.  PMRT  will  occur  at  the  earliest 
practicable  date  during  the  Production/Deployment  Phase.  Once  established,  the  date 
will  not  be  changed  without  the  concurrence  of  HQ  USAF . 

Finally,  the  system  nears  the  end  of  the  acquisition  process  and  arrives  at  the  thres¬ 
hold  of  operational  use  —  deployment.  The  Secretary  of  the  Air  Force  decides  that  the 
system  is  ready  to  be  deployed  to  the  using  command(s)  and  advises  the  SECDEF  of  his 
decision. 

Depioyment  begins  when  production  items  are  provided  to  and  used  by  operational 
units.  Turnover  to  'lie  using  command  is  effected. 

Turnover  is  the  formal  act  whereby  the  using  command  accepts  responsibility  for 
the  operation  and  maintenance  of  the  first  operating  units  of  a  new  system,  and  assumes 
property  accountability.  This  point  in  the  life  cycle  is  normally  identified  as  initial  opera¬ 
tional  capability  f IOC).  The  using  command  continues  operational  tests  to  develop  the 
most  effective  operational  tactics,  techniques,  and  standards. 

Some  time  following  initial  deployment  there  will  be  another  review  (Milestone  IV). 
This  review  marks  the  beginning  of  the  Operations  Support  Phase,  and  the  system  will 
remain  in  this  phase  until  its  retirement  fiom  the  active  inventory.  The  time  for  the 
Milestone  IV  review  will  be  established  by  the  DAE  and  will  depend  on  factors  such  as 
the  success  of  the  production  models,  the  state  of  technology  advances,  the  achievement 
of  support  ability  goals,  and  syst  em  readiness.  All  of  these  things  will  be  reviewed  so 
that  decisions  may  be  made  regarding  improvements  which  may  he  indicated  to  ensure 
the  system's  continued  capability  to  perform  the  mission  for  which  it  was  acquired.  If 
the  system,  based  upon  operational  performance  and  support  experience,  is  failing  to 
achieve  contractually  required  .standards,  then  the  Air  Force  will  determine  if  adequate 
warranties  exist  and  if  they  may  be  exercised  for  the  correction  of  the  deficiencies. 

The  Milestone  V  review  and  decisions  will  focus  on  the  system’s  operational 
effectiveness,  suitability,  and  readiness.  If  the  system  is  operating  as  required  but  still 
falls  short  of  meeting  current  needs,  then  consideration  may  be  given  to  initiating  either 
a  modification  program  to  enhance  the  system's  capability,  or  a  program  to  develop  a 
replacement  system.  Once  again  the  pivotal  role  of  mission  analysis  is  clear.  System 
development  begins  and  is  sustained  because  a  demonstrated  need  exists  and  is  continu¬ 
ally  evolving.  Existing  systems  are  evaluated  and  keep  changing  because  mission 
analysis  keeps  us  in  touch  with  the  constant  growth  and  changing  nature  of  the 
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—Identify  new  uses  for  tlie  system,  and 
—Reshape  tactics, 

OT&E  is  essentially  an  operational  assessment  during  which  the  system  is 
evaluated  against  operational  criteria  by  personnel  with  the  same  qualifications  as  those 
who  will  eventually  operate,  maintain,  and  support  the  system  when  it  is  deployed.  The 
role  of  T&E  is  stated  in  DODI  5000.3  as  follows: 

Test  and  evaluation  shall  begin  as  early  as  passible  and  be  conducted  throughout 
the  system  acquisition  process  to  assess  and  reduce  acquisition  risks  and  to  esti¬ 
mate  the  operational  effectiveness  and  operational  suitability  of  the  system  being 
developed  .  Successful  accomplishment  of  T&E  objectives  will  be  a  key 
requirement  for  decisions  to  commit  significant  additional  resources  to  a  pro¬ 
gram  or  to  advance  it  from  one  acquisition  phase  to  another 

Frequently  the  desire  to  maintain  program  continuity  and  pressure  to  meet  esta¬ 
blished  initial  operational  capability  commitments  dictate  a  decision  to  begin  a  low  rate 
initial  production  program  before  the  full  demonstration  of  design  stability.  This  over¬ 
lapping  of  the  FSD  and  production  phases,  called  concurrency ,  involves  the  acceptance  of 
certain  risks.  Since  system  testing  will  not  have  been  completed  before  the  low  rate  pro¬ 
duction  process  begins,  there  will  almost  certainly  be  test  failures  which  may  lead  to 
design  revisions  and  the  necessity  to  incorporate  changes  in  the  production  process  or  in 
delivered  prime  mission  equipment.  The  effect  of  those  changes  may  ripple  across  sup¬ 
port  equipment,  data,  simulators,  training  programs,  etc.  On  the  other  hand,  the  more 
closely  items  for  initial  operational  testing  resemble  the  final  production  configuration, 
the  sooner  a  stable  production  process  can  be  established.  Clearly  decisions  as  to  how 
much  concurrency  to  incorporate  into  the  acquisition  strategy  must  be  made  carefully  so 
that  the  expected  benefits  outweigh  the  potential  risks.  The  more  mature  the  system 
technology  and  the  more  stable  the  design  the  less  hazardous  is  a  decision  to  use  con¬ 
currency.  Current  policy  requires  a  Low  Rate  Initial  Production  Report  be  provided  to 
the  Secretary  of  Defense,  and  the  Congress  before  the  ADM  is  signed  to  authorize  Full 
Rate  Production/Deployment.  The  TRIP  Report  is  an  assessment  of  the  adequacy  of  the 
test  results  and  of  the  effectiveness  and  suitability  of  the  system  for  combat. 

Milestone  III  approval  by  the  SECDEF  constitutes  the  production/deployment  deci¬ 
sion,  which  is  documented  in  an  ADM  and  implemented  by  a  revision  to  the  PMD.  That 
decision  to  produce  for  operational  use  defines  the  initial  quantity  to  be  produced,  and 
approves  plans  for  future  production  ami  deployment.  If  no  significant  changes  have 
occurred  affecting  the  system  during  the  FSD/LRIP  phase  (i.e.,  major  design  change, 
large  increase  in  costs,  change  in  contractual  approach,  etc.)  ihe  decision  for  production 
may  be  delegated  to  the  individual  service  secretary. 

SECTION  VIII 

THE  PRODUCTION/DEPLOYMENT  AND  OPERATIONS  SUPPORT  PHASES 

The  actual  commitment  to  production  is  formally  and  contractually  accomplished 
at  the  onset  of  the  Production  Phase.  During  this  phase,  the  system,  including  training 
equipment,  spares,  facilities,  etc.,  is  produced  for  operational  use.  All  verification  of 
hardware  compliance  with  final  specification  requirements  is  usually  completed  no  later 
than  this  phase.  Any  decisions  deferred  from  FSD/LRIP  regarding  support  areas  such  as 
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challenges  to  successful  mission  accomplishment.  New  system  developments  begin  when 
technology  and  operational  needs  dictate. 

SECTION  IX 
CONCLUSION 

Having  described  the  typicai  system  acquisition  life  cycle  for  a  major  system,  one  is 
led  almost  inevitably  to  this  caveat  —  there  is  no  fixed,  well-lighted,  clearly  marked  high¬ 
way  from  a  deficiency  to  an  operational  capability.  Because  of  groundwork  laid  by 
laboratories  or  work  on  similar  systems,  a  program  could  begin  at  any  milestone  in  the 
life  cycle  or  in  the  middle  of  any  life  cycle  phase.  Because  of  unforeseen  developments, 
uncertainties,  or  mission  changes,  a  program  could  conceivably  be  required  to  redo  a 
phase.  Because  every  program  faces  a  formal  review  process  between  its  life  cycle  phases, 
and/or  when  any  DCP  threshold  is  breached,  every  program  is  in  periodic  jeopardy  of 
cancellation. 

Consequently,  the  system  acquisition  process  or  cycle  must  be  flexible,  and  in  fact  is 
deliberately  so,  in  order  to  be  responsive  to  the  truth  that  every  system  development  is 
unique.  But  the  guidance  is  there,  enunciated  dearly  enough  to  tell  any  program 
manager  what  he  is  expected  to  achieve  and  demonstrate.  Achievement  and  demonstra¬ 
tion  are  the  keys.  The  SF1CDFF  will  not  give  any  service  a  blank  check  based  upon 
proof  of  an  operational  deficiency.  The  acquisition  management  process  is  designed  to 
allow  him  to  periodically  review  both  the  requirement  and  progress  toward  its 
fulfillment,  and  to  commit  resources  incrementally  after  the  demonstrated  achievement  of 
program  milestones.  However,  the  incremental  commitment  of  resources  will  only  be 
adequate  to  reach  the  next  major  milestone.  The  DOl),  like  any  other  consumer  on  a 
budget,  intends  to  buy  only  what  it  needs  and  only  when  satisfied  that  the  product  will 
do  the  job. 
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OPERATIONAL  REQUIREMENTS  PROCESS 

The  operational  requirements  process  is  a  structural  process  of  analysis  and  itera¬ 
tive  refinement  by  which  HQ  USAF,  major  commands  ( MAJCONf)  and  Separate  Operat¬ 
ing  Agencies  (504)  can  document  operational  deficiencies  and  needs  for  validation  and 
solution.  The  process  is  structured  to  ensure  that  each  operational  deficiency  that  is  not 
within  command  solution  authority  can  be  documented,  coordinated,  validated,  com¬ 
pared  to  competing  deficiencies,  and  solved  through  acquisition  programs.  The  process 
begins  with  the  identification  of  operational  needs  and  continues  throughout  the  acquisi¬ 
tion  process  and  the  life  of  the  system.  It  provides  for  systematic  updates  to  ensure  that 
the  proposed  solution  will  meet  evolving  needs. 

Success  of  the  operational  requirements  process  demands  a  close,  continuing  rela¬ 
tionship  among  operating,  implementing,  supporting,  operational  test,  and  other  partici¬ 
pating  commands.  A  major  element  of  the  requirements  process  is  the  continual 
identification  of  meaningful  performance  tradeoffs  whereby  high-cost  features  providing 
only  marginal  performance  gains  are  deleted  from  the  system.  Incorporated  in  this  pro¬ 
cess  are  numerous  key  documents.  Though  most  of  them  will  be  mentioned,  this  descrip¬ 
tion  will  be  limited  predominantly  to  the  Statement  of  Operational  Need  (SON),  System 
Operational  Requirements  Document  ( SORD ),  and  the  Depot  Support  Requirements 
Document  ( DSRD ). 

Statement  of  Operational  Need  (SON): 

A  SON  is  required  for  needs  that  cannot  be  met  through  changes  in  tactics,  stra¬ 
tegy,  doctrine,  or  training  and  whose  solution  requires  a  new  development  or  upgrade  of 
an  existing  system.  It  describes  each  need  in  operational  terms  and  has  three  principal 
uses:  It  defines  an  operational  need,  documents  official  validation  of  the  need,  and  fur¬ 
nishes  preliminary  requirements  for  RDTVE  planning  (see  attachment  1  for  SON  for¬ 
mat). 

A  validated  SON  is  required  for  a  program  to  compete  for  funding  and  is  a  prere- 
t  quisite  for  HQ  USAF  preparation  of  a  Mission  Need  Statement  (MNS)  or  Air  Force  parti¬ 

cipation  in  a  Joint  System  Operational  Requirement  (JSOR).  A  SON  is  required  for  all 
programs  that  Involve  RDT&E  (3600)  and/or  procurement  (3010,  3020,  3080)  funding 
except  for  some  low-cost  class  V  modifications  and  communication  computer  systems. 

SON  Validation:  Operating  commands  must  address  any  additional  or  revised 
,  programmatic  data  and  resolve  major  issues.  Any  programmatic  changes  will  be  coordi¬ 

nated  with  the  implementing  command.  Resolution  of  issues  and  comments  should  be 
kept  on  file  by  the  operating  command.  The  operating  command  then  validates  and 
publishes  the  revised  SON  with  its  draft  Program  Decision  Package  (PDP).  The  vali¬ 
dated  SON  is  signed  by  the  MAJCOM  commander  or  designated  representative.  Mul¬ 
ticommand  SONs  will  fie  signed  by  the  lead  command  with  written  concurrence  by  the 
co-sponsoring  commands. 

Programming  and  Budgeting  for  Validated  Needs: 

All  Program  Decision  Packages  (PDPs)  that  require  funding,  through  the  pro- 
,  curement  or  RDTVE  appropriations  must  be  in  response  to  validated  SONs.  The  HQ 

USAF  Office  of  Primary  Responsibility  (OPR)  must  prepare  a  MNS  for  each  PDP 
expected  to  lead  to  acquisition  of  a  major  system  or  to  an  Air  Force  Designated 
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Acquisition  Program  (AFDAP).  The  MNS  must  be  submitted  formally  as  an  attachment 
to  the  Air  Force  Program  Objective  Memorandum  (POM).  I1Q  USAF  will  issue  a  Pro¬ 
gram  Management  Directive  (PMD)  to  implement  approved  programs  lor  which  resources 
are  identified  in  the  OSD-approved  Five-Year  Defense  Program  ( FYDP ). 

System  Operational  Requirements  Document  ( SORD ): 

The  operating  command  will  submit  a  SORD,  as  per  PMD  direction,  for  each 
funded  program  initiated  by  a  SON,  MNS  or  JSOR.  (See  attachment  2  for  SORD  for¬ 
mat).  During  the  early  part  of  the  Concept  Exploration/Definition  phase,  a  SORD  will 
be  developed  by  the  operating  command(s)  for  approval,  prior  to  Milestone  I.  As  the 
program  matures,  the  SORD  will  be  updated,  refined  and  approved  prior  to  Milestone  II 
and  again  at  Milestone  III. 

The  SORD  is  the  requirements  and  planning  document  prepared  to  address 
operational  and  support  needs.  Commands,  agencies  and  Air  Staff  offices  use  the  SORD 
to  identify,  assess  and  verify  the  adequacy,  accuracy,  and  completeness  of  requirements, 
program  factors,  and  planning  considerations.  The  SORD  amplifies  and  retines  the  con¬ 
tent  of  the  SON  and,  therefore,  must  be  developed  in  close  coordination  with  the  imple¬ 
menting  command  to  ensure  all  major  issues  are  resolved  prior  to  SORD  approval.  The 
SORD  further  explains  how  the  proposed  system  will  be  operated,  deployed,  employed 
and  supported.  It  assists  development  planning  by  documenting  the  cost/performance 
tradeoffs  conducted  as  the  concepts  evolve.  It  also  assists  in  scoping  the  set  of 
specifications  that  will  be  incorporated  in  the  Request  for  Proposal  ( RFP ),  serves  as  the 
basis  for  requirements  in  subsequent  program,  test  and  management  plans,  and  docu¬ 
ments  evolving  operational  requirements  which  may  be  changing  due  to 
cost/performance  tradeoffs  or  evolution  in  the  threat. 

Depot  Support  Requirements  Document  (DSHD): 

The  DSRD  is  a  stand-alone  document  prepared  by  the  PMD  designated  support¬ 
ing  command  (see  attachment  3  for  DSRD  format).  It  is  an  adjunct  to  and  complements 
the  SORD.  It  descrihes  the  supporting  command’s  plans  and  requirements  for  providing 
both  depot  maintenance  and  material  support  to  the  system  described  in  the  SORD. 
Normally  the  implementing  PMD  will  initiate  development  of  a  SORD  and  DSRD  simul¬ 
taneously. 

SON  FORMAT  (atch  1) 

I.  Mission. 

A.  Mission  Area:  Identify  primary  and  any  related  mission  areas  in  which  the 
need  exists. 

B.  Mission  Element  Need:  State  the  need  in  terms  of  the  requirement  to  perform 
one  or  more  military  tasks  having  certain  described  characteristics  --  not  in  terms  of  sys¬ 
tem  performance. 

C.  Joint  Service/Multinational  Applicability:  self-explanatory. 

II.  Basis  of  Need :  Identify  and  describe  the  basis  of  need  (i.e.,  change  in  enemy 
threat,  deficiency  in  existing  systems,  technological  opportunity,  expanded  mission,  etc.) 

III.  Assessment  of  Capabilities :  Briefly  summarize  and  assess  the  existing  and 
planned  DOD  and  allied  capabilities  for  performing  the  military  task(s)  described  in 
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para.  IB. 

IV.  Needed  Capability: 

A.  General  Operational  Requirement:  Briefly  describe  the  essential  qualitative 
and  quantitative  requirements  that  are  necessary  for  accomplishment  of  the  previously 
identified  military  tasks. 

B.  Possible  Solution(s):  Describe  alternatives  under  consideration. 

1.  Upgrades  to  existing/off-the-shelf  systems. 

2.  New  System. 

V.  Proposed  Program:  (normally  AFSO  input) 

A.  Acquisition  Strategy:  Describe  the  basic  program  strategies,  such  as:  pro¬ 
gram  structure,  competition,  contracting,  OT&E.  This  provides  underlying  rationale  for 
the  schedule  and  funding  profiles. 

B.  Schedule:  For  major  and  AFDAP  program,  include  a  schedule  that  shows  key 
events  in  concept  exploration  and  an  initial  estimate  of  milestone  II  &  III  and  Initial 
Operational  Capability  {IOC). 

C.  Funding  Profile:  Include  as  an  attachment  the  PDP  that  was  submitted  in 
the  POM  as  well  as  the  implementing  and  supporting  commands  estimated  funding 
profile  for  the  most  likely  solution  and  associated  assumptions. 

SORD  FORMAT  (at eh  2) 

I.  Mission: 

A.  Mission  Area:  Same  as  is  in  the  SON. 

B.  Mission  Element  Need:  Same  as  is  in  the  SON. 

C.  Joint  Service/Multinational  Applicability:  Same  as  is  in  the  SON. 

II.  Basis  of  Need:  Same  as  is  in  the  SON. 

III.  Assessment  of  Capabilities:  Same  as  is  in  the  SON. 

IV.  Proposed  Operational  System: 

A.  System  Description:  Self-explanatory 

B.  Required  System  Performance:  Specify  quantitative  values  for  operational 
and  logistics  support  performance  parameters. 

C.  Readiness  Requirements:  Identify  quantitative  and  qualitative  readiness 
requirements  to  reflect  reliability  and  maintainability  goals.  As  a  minimum,  the  follow¬ 
ing  parameters  will  be  described: 

1.  System  Readiness:  Operational  availability  and  sustainability  requirements. 

2.  Reliability: 

a.  Mission  Reliability. 

b.  Logistics  Reliability. 

3.  Maintainability. 

D.  System  Survivability:  Show  self- protection  capabilities,  system  design  or  per¬ 
formance  required  for  enhanced  survivability. 
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E.  Preplanned  Product  Improvement  (/',?/):  Describe  provisions  or  implication 
for  future  system  growth. 

F.  Deferred  System  Enhancements:  if  required,  show  enhancements  that  are 
currently  not  approved  or  funded  but  would,  if  incorporated,  materially  affect  the  overall 
design,  development  or  operational  capability. 

G.  Employment. 

1.  General  Employment  Description. 

2.  Mission  Scenario  and  Tactics. 

3.  Force  Structure. 

4.  Command  <t  Control  Structure. 

5.  Information  Systems. 

6.  Operational  Enviromm nt. 

7.  Environmental  Assessment. 

8.  Operational  Intelligence  Suj  port. 

9.  Mapping.  Charting.  A  Geodesy. 

10.  Unique  Weather  Support  Requirements. 

H.  Deployment. 

1.  Basing. 

2.  Mobility. 

3.  Support  Structure  survivability. 

I.  Support. 

1.  Maintenance  Planning. 

2.  Manpower  Support. 

a.  Manpower. 

b.  Personnel. 

c.  Human  Factors. 

d.  Supply  Support. 

J.  Related  Support  Factors. 

1.  Information  System  Support. 

2.  Logistics  Support  Management  Information. 

K.  Support  I'quipment . 

I,.  Technical  Data. 

M.  Training  &■  Training  Support. 

1.  Training  Agencies. 

2.  Anticipated  Training  Equipment. 

3.  Trained  Personnel  Required. 

N.  Computer  Resources  Support. 
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1.  Design  &  Development  Constraints. 

2.  Computer  Hardware  &  Software. 

3.  Security. 

O.  Facilities. 

P.  Packaging.  Handling,  Storage,  and  Transportation. 

Q.  Miscellaneous: 

1.  Energy  Management. 

2.  Survivability. 

3.  Standardization,  Interoperability,  and  Commonality. 

V.  Program  Data: 

A.  Program  Management  Directive. 

B.  Requirements  Documents. 

C.  Program  Status  ,{■  Schedule. 

D.  Planned  Test  Strategy. 

E.  Safety. 

F.  Programmatic  Data. 

C.  Level  of  Dissemination. 

II.  Security  Protection  for  Systems  A  Sites. 

I.  Threat  Assessment. 

J.  Requirements  Correlation  Matrix  (RC\f):  This  is  a  separate  attachment  to  the 
SORD. 

DEPOT  SUPPORT  REQUIREMENTS  DOCUMENT  (DSRD)  FORMAT 

(atch  3) 

I.  Program  Data: 

a.  Title 

b.  Point  of  Cont  act 

c.  Requirements  Document 

d.  Program  Management  Directive  (PMD) 

e.  System  Description 

II.  Depot  Maintenance  Concept: 

a.  Maintenance  Tasks 

b.  Base  Planning 

c.  Test  and  Fault  Isolation 

d.  Modular  Automatic  Test  Equipment 

e.  Depot  Repair 

f.  Technical  Data 
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g.  Depot  Training 

h.  Depot  Facilities 

III.  Material  Support  Concept: 

a.  Hardware  Support 

(1)  Engineering  Data  Requirement 

(2)  Technical  Orders 

(3)  Configuration  Control 

(4)  Force  Management 

(5)  Integrated  Diagnostics  Concept 

b.  Software  and  Firmware  Support 

(1)  Software  Partitioning 

(2)  Integrated  Software  Support  Facility 

(3)  Software  validation  and  Verification 

(4)  Software  Documentation 

c.  Spares  Support 

d.  Warranties  and  Guarantees 

e.  Data  Systems 

f.  Material  Management  Training  Requirements 

g.  Material  Management  Facility  Requirements 

IV.  Miscellaneous:  To  be  determined,  based  on  program  requirements. 
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LESSON 


ONE 


ACQUISITION  PROGRAM 
AFR  800-2 


DIRECTED  EFFORT  FUNDED  THROUGH: 

1.  PROCUREMENT  APPROPRIATIONS 

2.  SECURITY  ASSISTANCE  PROGRAM;  OR 

3.  RESEARCH,  DEVELOPMENT,  TEST  AND 
EVALUATION  APPROPRIATIONS 


PROVIDES  A  NEW  OR  IMPROVED  CAPABILITY  FOR  A  VALIDATED 
NEED. 


INCLUDES  MISSION  RELATED  EQUIPMENT  AS  WELL  AS 
SUPPORTING  EQUIPMENT,  SYSTEMS,  PROJECTS  AND  STUDIES. 
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TYPES  OP  FUNDS 


PROCUREMENT  -  3010  -  AIRCRAFT 
3020  -  MISSILE 
3080  -  OTHER  PROCUREMENT 

RESEARCH,  DEVELOPMENT,  TEST  AND  EVALUATION  -  3600 
MILITARY  CONSTRUCTION  -  3300 

OPERATIONS  AND  MAINTENANCE  -  3400 


*  *  * 


DIRECTED  EFFORT 

PROGRAM  MANAGEMENT  DIRECTIVE  ( PMD ) 

-  HQ  USAF  TO  MAJOR  COMMAND 

AFSC  FORM  56 

-  HQ  AFSC  TO  PRODUCT  DIVISIONS 

PROGRAM  ACTION  DIRECTIVE  (PAD) 

-  HQ  AFLC  TO  CENTERS 

PURCHASE  REQUEST  (PR) 

-  ANYBODY  TO  PROGRAM  MANAGER 
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VALIDATED  NEED 


0  OPERATING  COMMAND  ANALYZES  CAPABILITY  TO  MISSION 
BASED  ON: 

*  CURRENT  CAPABILITY 

*  THREAT  ANALYSIS 


0  IDENTIFIED  DEFICIENCIES  ARE  DOCUMENTED  IN  STATEMENT 
OF  OPERATIONAL  NEED  (SON) 

0  SON  COORDINATED  WITH  OTHER  COMMANDS 


*  *  * 


SYSTEM 


INCLUDES  MISSION  EQUIPMENT  AND  ALL  SUPPORT  REQUIRED  FOR 
OPERATIONS  AND  MAINTENANCE  SUCH  AS: 


SUPPORT  EQUIPMENT 
TRAINING  EQUIPMENT 
PERSONNEL 
TECHNICAL  ORDERS 


TRAINING 

SPARES 

PACKAGING 

FACILITIES 
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CATEGORIES  OF  AIR  FORCE  ACQUISITION  PROGRAMS 


0  DOD  MAJOR  PROGRAMS 

0  AIR  FORCE  DESIGNATED  ACQUISITION  PROGRAMS 

0  NON-MAJOR  PROGRAMS 


★  *  ★ 


DOD  MAJOR  PROGRAM  CRITERIA 

0  RESOURCES 

§  200M  IN  RDT6.E 
$  IB  IN  PRODUCTION 

0  RISK  OR  URGENCY 

0  JOINT  SERVICE  USAGE 

0  CONGRESSIONAL  INTERESTS 


1-31 


AIR  FORCE  DESIGNATED  ACQUISITION  PROGRAM  CRITERIA 


0  RESOURCES 

$  1 00-200M  IN  RDT&E 
$500M-$ 1 B  IN  PRODUCTION 

0  RISK  OR  URGENCY 

0  OUTSIDE  INTEREST 


*  *  * 


NON-MAJOR  PROGRAM  CRITERIA 

0  RESOURCES 

<  $  1 00M  IN  RDT&E 

<  5500M  IN  PRODUCTION 

0  NOT  DESIGNATED  AS  DOD  MAJOR  OR  AIR  FORCE 
DESIGNATED  PROGRAM 
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LESSON  2 


LESSON  TITLE:  Internal  Program  Management 
TIME:  1  hr 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 

the  types  of  internal  organizations  available  to  program  managers, 

the  advantages  and  disadvantages  of  each  kind  of  organization, 

and  the  functions  normally  found  in  a  program  office. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Describe  the  advantages  and  disadvantages  of  a  functional  type 
organization. 

b.  Describe  the  advantages  and  disadvantages  of  a  project  type  organization. 

c.  Describe  the  advantages  and  disadvantages  of  a  matrix  type  organization. 

d.  State  the  environment  for  which  the  project  type  organization  is 
best  suited. 

e.  State  the  environment  for  which  the  functional  type  organization  is 
best  suited. 

f.  Describe  the  functional  specialties  normally  found  in  an  Air  Force 
program  office. 

TOPIC  INTRODUCTION: 

Now  that  you  understand  what  the  system  concept  is,  you  need  to  understand  how 
human  resources  are  typically  organized  to  bring  that  weapon  system  to  fruition. 
Organizations  are  typically  organized  along  functional,  project,  or  matrix  lines.  The  type 
of  organization  you  are  working  in  depends  on  where  you  work  (i.e.,  Air  Force  Systems 
Command  or  Strategic  Air  Command,  as  examples).  Some  organize  along  functional 
lines  of  authority  (as  in  the  early  1960s),  some  along  project  lines  (like  at  most  labora¬ 
tories),  and  some  along  matrix  lines  (like  at  several  product  divisions).  One  of  the  first 
issues  addressed  should  be  what  type  of  organization  is  pertinent  to  your  program  and 
how  does  this  affect  your  management  style?  The  type  of  organizational  structure  prob¬ 
ably  will  depend  on  the  policies  of  the  local  base,  the  mission  need  you  are  fulfilling,  and, 
ideally,  the  method  that  you  determine  is  the  most  efficient  and  effective  structure.  Nor¬ 
mally,  the  program  manager  has  to  live  with  the  organizational  structure  that  is  set  by 
policy,  superiors,  or  availability  of  resources.  Either  way,  a  program  manager  needs  to 
understand  the  advantages  and  disadvantages  of  each  type  of  organizational  structure  in 
order  to  maximize  a  given  situation.  This  lesson  describes  the  three  types  of  organiza¬ 
tions,  the  advantages  and  disadvantages  of  each,  and  how  this  affects  program  manage¬ 
ment.  Think  about  organizational  structures  in  terms  of  your  own  experiences  and  what 
would  be  best  for  meeting  your  acquisition  requirements.  As  program  manager,  you  need 
to  understand  the  capabilities  and  limitations  of  your  subordinates,  peers,  and  superiors 
in  managing  acquisition  programs. 
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METHOD  OF  INSTRUCTION:  Lecture/Discussion 
INSTRUCTIONAL  MATERIALS: 

a.  Article,  Matrix  Management:  Is  it  Right  for  Weapons  Acquisition?, 
by  Dr  Patterson,  DSMC  Program  Manager’s  Newsletter 

b.  Internal  Management  videotape 

c.  Lesson  viewgraphs 

ALT)IO- VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 

REFERENCES:  Cable,  Dwayne  and  Adams,  John  R.,  Organizing  for  Project  Manage¬ 
ment.  (Drexel  Hill:  Project  Management  Institute,  1982) 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Matrix  Management:  Is  it  Right  for  Weapons  Acquisition? 

b.  Scan  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  Name  the  three  basic  types  of  organizational  structures  and  discuss  the  charac¬ 
teristics,  advantages,  and  disadvantages  of  each.  [The  advantages  and  disadvantages  of 
each  organizational  structure  are  listed  in  the  course  text  and  videotape.] 


2.  Give  some  major  guidelines  for  choosing  an  organizational  form  for  a  project. 


3.  In  the  matrix  organizational  structure,  what  tasks  should  the  Project  Manager 
have  authority  over?  .  .  .  the  F unctional  Manager? 


4.  List  some  of  the  major  functional  areas  found  in  a  typical  System  Program 
Office  (SPO)l 


5.  Why  is  the  SPO  so  important  in  weapon  system  acquisitions?  [Acronyms  intro¬ 
duced  in  this  lesson,  and  their  descriptions] 
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MATRIX  MANAGEMENT: 

Is  It  Right  for  Weapons  Acquisition? 

by 

Or.  Michael  8.  Patterson 
Babson  College 


Matrix  management  is  a  compromise  between  orga¬ 
nizing  by  function  and  organizing  by  project.  Currently,  it 
is  the  subject  of  heated  controversy  within  the  weapons 
acquisition  community  where  the  mere  mention  of  ma¬ 
trix  management  brings  forth  staunch  praise  or  anguished 
condemnation. 

Regardless  of  its  merits,  it  is  clear  that  matrixing 
means  change,  a  departure  from  the  established  way  of 
doing  things  and  an  opportunity  to  either  improve  or 
damage  organizational  performance.  Recently,  organiza¬ 
tions  such  as  the  Aeronautical  Systems  Division  at 
Wright-Patterson  AFB,  Ohio,  and  the  Electronic  Systems 
Division  at  Hanscom  AFB,  Massachusetts,  have  substan¬ 
tially  increased  the  degree  of  matrixing  within  their  units. 
Furthermore,  this  appears  to  be  only  the  beginning  of  a 
trend  that  will  extend  to  many  other  weapons  acquisition 
organizations. 

The  purpose  of  this  article  is  to  briefly  trace  the 
evolution  of  matrix  management  and  the  two  manage¬ 
ment  forms  that  preceeded  it  as  they  were  developed  by 
industry  and  later  adopted  by  weapons  acquisition  orga¬ 
nizations.  In  addition,  some  cautions  will  be  offered 
concerning  the  employment  of  matrixing  in  weapons 
acquisition  organizations. 

The  Functional  Structure 

Until  the  early  1 9f>0s,  the  func  lional  struc  tore  was  a 
common  organizational  form  for  aerospace  companies 
as  well  as  for  many  other  enterprises.  An  organization  in 
which  common  skills  or  processes  were  grouped  together 
offered  several  advantages  for  companies  in  that  it  pro¬ 
moted  the  efficient  use  of  technical  resources  and  helped 
maintain  the  quality  of  those  resources.  A  functional 
structure  also  facilitated  corporate  memory  in  regard  to 
technical  solutions  while  offering  advantages  concerning 
morale  and  employee  motivation. 


•  Profpm  MaMgtn  NtwiteUrr 
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How  did  a  functional  structure  provide  these  advan¬ 
tages?  Efficient  y  in  functional  organizations  was  gained 
by  pooling  similar  skills  into  departments.  While  an  indi¬ 
vidual  project  might  not  warrant  the  full  services  of  a 
narrow  specialization,  a  specialist  assigned  to  a  functional 
department  could  be  kept  fully  employed  supporting 
several  projects.  This  enabled  the  company  to  hire  highly 
specialized  personnel  and  by  allocating  their  efforts,  keep 
them  fully  employed  The  economy  of  scale  realized  by  a 
functional  organization  allowed  companies  to  retain 
these  specialists  and  thus  maintain  or  improve  the  overall 
caliber  of  their  technical  force. 

Functional  structures  also  offered  the  advantage  of 
providing  a  corporate  memory  in  each  functional  area. 
Rather  than  loc  king  them  away  in  a  particular  project 
office,  the  successes,  failures  and  lessons  of  earlier 
projects  were  made  accessible  to  all.  For  high  technology 
companies,  this  ready  access  to  experience  was  a  valu¬ 
able  asset. 

A  further  advantage  of  the  func  tional  structure  lay  in 
the  areas  of  morale  and  motivation  Each  functional 
department  provided  a  home  base  for  its  personnel,  one 
that  could  provide  career  development  and  allow  indi¬ 
viduals  to  progress  within  their  technical  area.  This,  in 
turn,  promoted  employee  loyalty  and  provided  an  incen¬ 
tive  to  remain  with  the  organization 

Functionally  structured  organizations  also  had  a  sig¬ 
nificant  disadvantage  They  were  not  responsive  to 
project  schedules.  Although  they  increased  technical 
capability,  the  fragmented  efforts  of  individual  technical 


departments  often  served  as  an  impediment  to  timely 
project  coordination.  This  was  of  particular  concern  to 
aerospace  companies  as  they  became  increasingly  in¬ 
volved  with  hiRh  priority,  lightly  sc  heduled  space  pro¬ 
grams  The  problem  was  further  aggravated  by  employ¬ 
ee's  understandable  tendency  to  place  their  loyalties  with 
their  func  tional  department  rather  than  commit  them¬ 
selves  to  the  success  of  individual  projects. 

it  was  this  lack  of  responsiveness  to  schedules  that 
led  aerospace  corporations,  and  later  their  counterparts 
in  government,  to  search  for  a  better  form  of  organiza¬ 
tion  Specifically,  they  wanted  a  structure  that  was  re¬ 
sponsive  to  both  accelerated  technology  and  the  de¬ 
mands  of  high  priority  programs.  The  search  led  to  the 
project  structure. 

The  Project  Structure 

In  this  organizational  form  the  diverse  specialities 
required  for  a  project  were  assigned  to  a  single  office, 
until*  the  direction  of  a  project  manager '  The  result  was 
an  organization  that  was  goal  oriented  and  that  could 
internally  achieve  program  coordination.  Thus,  the 
project  offic  e  was  able  to  successfully  respond  to  pro¬ 
gram  schedules 

There  were  several  strengths  offered  bv  project  orga¬ 
nizations  Not  only  was  program  integration  lac  ilitated  bv 
bringing  the  diverse  functions  under  one  organizational 
roof,  but  it  was  found  to  Ire  a  more  adaptable  form  of 
organization  with  an  improved  fac  ility  for  problem  solv¬ 
ing  These  qualities  were  of  particular  importance  in 


Figure  1. 

A  Functional  Organization  (Industry) 
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programs  with  rapidly  changing,  high  priority  require¬ 
ments.  finally,  it  was  found  that  as  program  direction  and 
coordination  improver)  under  a  single  prrtgram  manager, 
budget  performance  also  tended  to  improve.' 

However,  the  advantage  of  improved  coordination 
and  adherent  e  to  schedules  and  budgets  was  offset  by 
several  disadvantages.  Project  management  was  often 
found  to  lie  an  expensive  and  inefficient  use  of  resourt  es. 
As  one  company  manager  recently  com|>lained,  “We 
had  six  of  everything.  We  had  to  operate  at  92  percent 
capacity  just  to  break  even."' 


Project  structures  also  had  a  weakness  in  regard  to 
employee  morale  While  functional  organisations  pro¬ 
vided  a  degree  of  stability,  projet  t  offices  were  intended 
to  be  of  comparatively  short  duration,  spanning  only  the 
life  of  the  project.  Consequently,  there  was  a  tendency 
for  project  members  to  become  uneasy  about  their  fu¬ 
ture.  With  no  one  to  look  to  for  career  progress  or  long 
term  development,  morale,  in  some  cases,  suffered. 

If  was  also  found  that  project  managers  had  an 
understandable  tendency  to  retain  their  best  and  most 
experienced  people.  As  a  result,  valuable  experience 


Figure  2. 

A  Project  Organization  (Air  Force  Systems  Command) 
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remained  lock'd  in  each  project  office  and  the  lessons  of 

the  project  were  not  shared. 

Because  of  these  shortcomings,  aerospace  and  de¬ 
fense  organizations  again  searched  for  a  new  organiza¬ 
tion  structure  This  search  led  to  matrix  management 

The  Matrix  Structure 

In  a  malnxed  organization,  an  attempt  was  made  to 
retain  thp  benefits  of  both  the  functional  and  project 
organizations  while  avoiding  their  inherent 
disadvantages  For  defense  acquisition  organizations  this 
led  to  the  matrixing  of  individual  functions  such  as 
procurement  or  engineering  In  other  •  ases,  such  as  that 
of  a  large,  aggregate  program  office,  all  personnel 
functions  were  matrixed  (see  Fig  4). 

When  matrixed.  personnel  are  permanent  members 
of  their  funi  tional  departments  hut  are  assigned  on  a  full 
time  or  part  lime  basis  to  protect  organizations,  the  result 
is  a  dual  line  of  authority  under  whic  h  matrixed  personnel 


must  answer  to  both  the  individual  program  manager  and 
the  supervisor  of  the  functional  department.  Inherent  in 
the  dual  authority  is  a  power  balance  between  the  project 
manager  and  the  functional  manager.  This  (lower  balance 
is  an  important  aspect  of  matrix  management  and  as  one 
author  |>oints  out,  "While  equal  power  is  an  unachieva¬ 
ble  razor  s  edge,  a  reasonable  halanc  e  can  be  obtained 
through  enforc  ed  collaboration  on  budgets,  dual  infor¬ 
mation  and  repenting  systems  and  dual  authority 
relations 

In  general,  it  may  lie  said  that  resource  matiixmg 
avoids  the  schedule  and  budget  laxity  of  lunc  (tonal 
management,  and  in  theory,  avoids  the  maldistribution  of 
resources  sometimes  found  in  project  management  At 
the  same  time,  it  promotes  the  technical  development 
inherent  in  functional  management  and  the*  coordination 
and  responsiveness  inherent  in  projec  t  management 

As  in  the  case  with  other  organization  forms, 
matrixing  is  not  without  pitfalls.  The  dual  authority 
relalionship  can  breed  conflict,  uncertain  direction,  and  a 


Figure  3. 

A  Simplified  Matrix  Organization  for  Systems  Acquisition  Management 
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ix-rvading  atmosphere  of  management  by  t  ompromise. 
In  .ukiition  to  these  universal  pitfalls,  there  may  Ire 
addition, il  matrixing  hazards  that  may  he  eru  iMinteierl  as 
weapons  acquisitions  organizations  matrix  their 
resources. 

Hazards  for  Weapons 
Acquisition  Organizations 

Although  matrixing  is  an  attractive  solution  to  a 
number  of  ac  quisition  problems,  matrixing  may  also  lie- 
very  difficult  for  these  organizations  to  implement.  This 
difficulty  focuses  on  the  areas  of  personnel  resistance, 
increased  internal  conflict  and  the  problem  of  establish¬ 
ing  a  power  balance.  Difficulties  may  also  arise  from  the 
aspects  of  matrixing  that  simply  go  against  the  gram  of 
military  organization 


Matrixing  destroys  or  alters  many  of  the  established 
methods  of  operating  and  leads  to  reduced  authority  for 
some  dec  ision  makers  Thus,  it  may  c  reate  or  at  least 
surface  conflict.  The  result  is  that  significant  resistance 
may  materialize  from  several  sources  within  the  orga¬ 
nization.  Although  this  alone  should  not  rule  out  the 
c  hange,  it  should  lx-  weighed  against  the  advantages  of 
changing  to  a  matrixed  structure 

A  fundamental  difficulty  with  matrixing  is  that  it 
results  in  two  or  more  lines  of  authority  exercising  deci¬ 
sion  making  power  over  a  project.  Sajd  one  of  General 
tlec  trie’s  managers  after  undergoing  matrixing,  “The 
whole  structure  is  intended  to  force  conflict  to  the  sur¬ 
face."’  Surfac  ing  c  onflict  is  desirable  but  only  when  an 
organization  is  adequately  prepared  to  resolve  it. 


Figure  4. 

A  Large  Project  Office  That  Has  Been  Internally  Matrixed 
(Simulator  System  Program  Office,  ASD  (AFSC)) 
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As  previously  mentioned,  an  organizational  power 
balance  is  <  rut  ial  to  the  success  of  matrix  management. 
However,  the  whole  concept  of  dual  authority  is  contrary 
to  the  unity  of  command  that  military  organizations  have 
practiced  for  centuries.  These  long  ingrained  tenets  are 
not  easily  overcome  Where  the  important  e  of  this 
power  balanc  e  is  not  recognized  and  resolved,  attempts 
towards  a  successful  matrix  will  ultimately  fail. 

In  industry,  some  of  the  profionents  of  matrix 
management  see  it  as  a  means  of  getting  out  from  under 
the  paper  crush  and  speeding  up  decision  making  How¬ 
ever,  decision  making  will  only  be  accelerated  if  more 
dec  ision  authority  is  delegated  to  derision  makers  at  the 
program  level  In  weapons  acquisition,  decision  making  is 
a  highly  structured  and  tealously  guarded  prerogative. 
Significant  decision  making  is  maintained  at  least  one 
level  and  often  several  levels  above  the  program  man- 
ager  Consequently,  a  lowered  level  for  decision  making 
will  not  necessarily  result  from  the  adoption  of  a.  matrixed 
system 

Ultimately,  the  dec  ision  to  adopt  matrix  management 
should  be  based  on  a  careful  analysis  of  ear  h  acquisition 
funr  tion  and  the  advantages  versus  disadvantages  of 
placing  that  function  in  a  matrixed  organization  It  may  be 
found  that  while  certain  func  tions  should  be  matrixed, 
others  should  he  left  where  (ties  are  lest  additional 
matrixing  reduce  organizational  effectiveness.  Decision 
makers  should  he  alert  to  rec  ogntzing  this  point  of  dimin¬ 
ishing  returns  and  not  simply  he  swept  along  in  the  tide  of 
organizational  c  hange. 

In  summary,  matrix  management  is  a  synthesis  of  its 
predecessors  and  as  such  provides  mans  improvements 
for  managing  high  priority,  technically  demanding  and 


rapidly  changing  programs.  Is  it  tight  for  weapons  sys¬ 
tems  acquisition?  Only  a  careful  and  judicious  analysis  of 
each  situation  can  provide  that  answer.  Matrix  manage¬ 
ment  has  much  to  offer,  but  for  it  to  be  sure  essful  it  must 
be  well  conceived,  skillfully  employed  and  properly  tai¬ 
lored  to  the  problems  at  hand. 


I)r  Patterson  is  a  member  of  the  Department  of 
Management  at  Babson  College,  Babson  Park,  Mass  A 
Program  Management  Course  7f>  2  graduate,  he  has 
served  in  several  program  management  positions  in  the 
Air  Forte  including  systems  test,  proc  urement  and  Dep- 
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INTERNAL  PROGRAM  MANAGEMENT 


0  SIZE 

0  INTERDEPENDENCE 

0  INPUT 

0  PROCESS 

0  OUTPUT 


ORGANIZATION 


FIVE  KEY  ELEMENTS 


TWO  OR  MORE  INDIVIDUALS, 

WHOSE  COMMON  GOALS  CAN  BE 
MORE  READILY  ACHIEVED 
THROUGH  INTERDEPENDENT 
(COOPERATIVE)  ACTION, 

BY  TAKING  IN  MATERIALS, 
ENERGY  AND  INFORMATION 
FROM  THE  ENVIRONMENT  IN 
WHICH  THEY  EXIST, 

WHO  DEVELOP  COORDINATIVE  AND 
CONTROL  RELATIONSHIPS  TO 
CAPITALIZE  ON  THEIR  INTERDE¬ 
PENDENCE  WHILE  OPERATING  ON 
THESE  INPUTS, 

AND  RETURN  THE  MODIFIED 
INPUTS  TO  THE  ENVIRONMENT 
IN  AN  ATTEMPT  TO  ACCOMPLISH 
THE  GOALS  THAT  INTERDEPEN¬ 
DENCE  WAS  MEANT  TO  MAKE 
POSSIBLE. 


2- 


\ 


FUNCTIONAL  ORGANIZATION 

ADVANTAGES 

0  TECHNICAL  EXCELLENCE 

0  FLEXIBILITY  IN  USE  OF  SPECIALIST 

0  CAREER  DEVELOPMENT  AND  PROGRESSION 

0  BUDGETARY  CONTROL 

0  DEFINED  AUTHORITY  AND  RESPONSIBILITY  RELATIONSHIPS 

0  STRUCTURED  COMMUNICATION  CHANNELS 


\ 


*  *  * 


FUNCTIONAL  ORGANIZATION 

DISADVANTAGES 

0  NOT  RESPONSIVE  TO  PROGRAM  OBJECTIVES 

0  COORDINATION  AMONG  FUNCTIONS  COMPLEX 

0  DECISION  MAKING  BECOMES  CENTRALIZED 
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PURE  PROJECT  ORGANIZATION 
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PROJECT  ORGANIZATION 

ADVANTAGES 

0  RESPONSIVE  TO  PROGRAM  OBJECTIVES 

0  RAPID  REACTION  TIME 

0  INTEGRATION  FACILITATED 


*  *  * 


PROJECT  ORGANIZATION 

DISADVANTAGES 

0  COST  OF  MAINTAINING  ORGANIZATION 

0  CAREER  PROGRESSION 
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MATRIX  ORGANIZATIONS 

ADVANTAGES 

0  RESPONSIVE  TO  PROGRAM  OBJECTIVES 

0  HIGHER  MANPOWER  UTILIZATION  SPECIALISTS  AVAILABLE  TO  ALL 
PROGRAMS 

0  FUNCTIONAL  SPECIALISTS  HAVE  A  '‘HOME"  TO  RETURN  TO 

0  BETTER  BALANCE  AMONG  COST,  SCHEDULE  AND  PERFORMANCE  IS  OBTAINED 


*** 


MATRIX  ORGANIZATIONS 

DISADVANTAGES 

0  DUAL  REPORTING  RELATIONSHIPS 

0  RESOURCE  ALLOCATION  CONFLICTS 

0  SELF-PERPETUATING  PROGRAMS 

0  BLURRED  LINES  OF  AUTHORITY  AND  RESPONSIBILITY 

0  CAREER  PROGRESSION  OF  FUNCTIONAL  PERSONNEL 

0  COMPLEXITY  OF  MANAGEMENT 
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LESSON  3 


LESSON  TITLE:  External  Program  Management 
TIME:  1  hr 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 

the  organizations  external  to  the  program  office  which  participate  in 

the  acquisition  of  systems  and  the  nature  of  their  involvement. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  State  the  responsibility  of  the  Program  Manager. 

b.  Describe  how  the  program  manager  receives  direction. 

c.  State  the  purpose  and  command  level  of  each  of  the  following  reviews: 

(1)  Management  Assessment  Review  (MAR) 

(2)  Command  Assessment  Review  (CAR) 

(3)  Secretary  of  the  Air  Force  Program  Assessment  Review  (SAFPAR) 

(4)  Selected  Acquisition  Report  (SAR). 

d.  Identify  and  give  examples  of: 

(1)  an  Implementing  Command 

(2)  a  Supporting  Command 

(3)  an  Operating  Command 

(4)  a  Participating  Command. 

e.  Describe  the  roles  of  the  PEM,  SYSTO,  GAO,  and  AFPRO. 

TOPIC  INTRODUCTION: 

With  the  concept  of  system  acquisitions  and  typical  organizational  structures  intro¬ 
duced,  you  also  need  to  be  aware  of  the  many  external  participants  that  affect  the  suc¬ 
cessful  outcome  of  your  program.  There  are  far  too  many  participants  in  the  acquisition 
process  to  talk  about,  in  an  introductory  course.  Therefore,  we  are  going  to  address  only 
a  sample  of  participants;  those  that  are  usually  very  important  to  attaining  program 
goals  and  objectives.  To  set  the  stage  --  the  program  manager  is  the  focal  point  in  sup¬ 
porting  goals  and  objectives.  Clearly,  the  program  manager  is  the  one  responsible  for 
meeting  technical,  schedule,  cost,  and  supportability  goals  (Reference  AFR  800-2).  The 
difficulty,  in  meeting  these  goals,  is  where  the  program  manager  earns  her  paycheck. 
The  program  manager  is  the  one  implementing  DOD,  USAF,  and  AFSC  direction.  She 
must  decide  daily  acquisition  issues,  sometimes  conflicting  to  each  other,  in  fulfilling  her 
mission  and  meeting  her  baseline  (or  agreements).  Sometimes  issues  become  too  complex 
and  cannot  be  resolved  at  the  program  manager  level;  therefore,  they  must  be  elevated  to 
higher  decision  levels.  The  reporting  process  is  very  crucial  to  resolving  these  issues  and  in 
conveying  confidence  about  your  management  capability.  It  is  through  preparation  for, 
and  presentation  in,  the  reporting  process  that  external  participation  in  your  program  is 
heavy.  Addressed  in  this  lesson  are  examples  of  some  of  the  different  acquisition  com¬ 
mands  and  external  organizations  that  might  significantly  affect  the  success  of  your  pro¬ 
gram.  These  can  be  excellent  sources  of  information,  and,  significant  members  of  your 
acquisition  team;  but,  if  you  ignore  them,  they  can  hurt  your  success  later  with  non- 


support,  or  even  worse,  opposition  to  your  program.  So  far,  the  focus  has  been  on 
understanding  some  basic  acquisition  terminology  and  the  types  of  organizations  typi¬ 
cally  found  in  System  Program  Offices.  Understanding  the  role  of  external  participants 
involved  with  weapon  system  acquisitions  is  important  for  all  program  managers. 


METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  Program  Management ,  by  Capt  Adler,  AF1T/LSY 

b.  External  Management  videotape 

c.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  DOD  Directive  5000.1,  Major  System  Acquisition 

b.  DOD  Instruction  5000.2,  Defense  Acquisition  Program  Procedures 

c.  AFR  800-2,  Acquisition  Program  Management 

d.  AFR  800-5,  Selected  Acquisition  Reports 

e.  AFSCR  800-1,  Command  Review  of  System  Acquisition  Programs  and  Test 
Resources 

f.  AFSCR  550-10,  Focus  on  the  User 

g.  AFSCR  550-11,  Give  the  User  Value 

h.  AFSCR  550-20,  People 

i.  AFSCR  550-22,  Program  Management  Baseline 

j.  AFR  57-1,  Operational  Requirements:  Operational  Needs,  Requirements, 
and  Concepts 

k.  AFR  80-14,  Test  and  Evaluation 

l.  AFR  800-4,  Transfer  of  Program  Management 

m.  AFR  800-25,  Acquisition  Program  Responsibility  Baselining 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Program  Management 

b.  Scan  lesson  viewgraphs 


3-2 


DISCUSSION  QUESTIONS: 


1.  Assume  you  have  various  commands  represented  in  your  SYS  100  seminar. 
Each  command  has  a  different  role  and  mission  in  the  outcome  of  your  acquisition  pro¬ 
gram.  As  Program  Manager,  your  main  concern  is  fielding  a  weapon  system  that  is  on 
cost,  within  schedule,  performs  to  technical  requirements,  and  is  iogistically  supportable. 
With  one  person  each  taking  the  role  of  an  implementing,  supporting,  participating,  and 
operating  command,  discuss  everyone’s  goals  and  objectives?  Are  they  the  same?  Should 
they  be  the  same?  How  would  they  differ?  Describe  some  of  the  tradeoffs  involved  with 
each  command  in  program  management,  especially  in  the  early  phases  of  the  acquisition 
life  cycle? 


2.  Differentiate  between  Air  Training  Command  being  directed  to  be  a  participat¬ 
ing  command  for  one  program  and  an  operating  command  for  another  program? 


3.  The  Program  Element  Monitor  ( PEM ),  newly  assigned  to  your  program,  wants 
know  what  are  the  key  elements  of  your  program  because  she  has  an  upcoming  congres¬ 
sional  deadline.  What  information  is  indicative  of  the  data  your  PEM  needs  to  fairly 
represent  your  program? 


4.  What  might  be  some  of  the  key  areas  that  would  be  reviewed  at  the  Management 
Assessment  Review  (MAR),  Command  Assessment  Review  (CAR),  Secretary  of  the  Air 
Force  Program  Assessment  Review  (SAFPAR),  and  the  Selected  Acquisition  Report 
(SAR)? 


[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 
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AFPRO 

CAR 

GAO 

MAR 

PAD 

PEM 

PEO 

SAFPAR 

SAR 

SYSTO 


Air  Force  Plant  Representative 
Command  Assessment  Reviews 
General  Accounting  Office 
Management  Assessment  Reviews 
Program  Action  Directive 
Program  Element  Monitor 
Program  Executive  Officer 

Secretary  of  the  Air  Force  Program  Assessment  Review 
Selected  Acquisition  Reports 
Systems  Officer 
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PROGRAM  MANAGEMENT 

PROGRAM  MANAGER  RESPONSIBILITY 

During  phases  of  the  acquisition  life  cycle,  the  single  Air  Force  manager  leading 
the  process  of  effectively  attaining  established  cost,  schedule,  performance,  and  support 
objectives  is  the  program  manager.  The  program  manager  accomplishes  this  through  the 
efficient  use  of  government  and  contractor  resources.  He  is  the  one  who  answers  the  tough 
questions  involving  trade-offs  throughout  the  weapon  system’s  development  and  procure¬ 
ment.  The  program  manager  is  also  the  person  responsible  for  delivering  the  weapon  sys¬ 
tem  according  to  established  parameters  in  the  program  baseline  (as  outlined  in  AFR 
800-25  ...  and  AFR  800-6). 

One  of  the  most  difficult  responsibilities  of  the  program  manager  is  getting  all  sup¬ 
porting  agencies  to  provide  their  support  and  resources  in  coordination  with  the  program 
goals  and  objectives.  The  program  manager’s  role  involves  fulfilling  the  goals  and  objec¬ 
tives,  as  established  by  government  and  contractor  decision  makers,  and  later  described 
in  System  Program  Office  (SPO)  documentation.  This  documentation  might  include 
describing  such  activities  as  Air  Force  Logistics  Command’s  ( AFLC)  involvement  early  in 
the  acquisition  process  and  Air  Training  Command’s  ( ATC)  inputs  for  training  require¬ 
ments  involving  technical  order  generation  and  support  equipment  development.  Other 
documentation  might  also  include  military  construction  programs,  test  and  evaluation 
activities  as  managed  by  the  Air  Force  Operational  Test  and  Evaluation  (AFOTEC) 
division,  system  engineering  activities,  configuration  management  plans,  material  availa¬ 
bility  with  foreign  sources,  and/or  virtually  any  possible  factor/event  affecting  the  pro¬ 
gram. 

Clearly,  the  program  manager’s  role  is  not  limited  to  one  specific  phase,  issue,  plan, 
or  activity  but  encompasses  the  whole  realm  of  the  system  life  cycle.  Complicating  this 
role  is  the  fact  that  decisions  need  to  be  made  in  an  environment  where  the  system  being 
developed  usually  does  not  exist.  Also  frustrating  is  the  increasing  level  of  outside 
influence  making  reaction  time,  program  reporting,  and  decision  making  even  more  com¬ 
plex. 

While  all  of  this  may  seem  impossible  to  control,  this  is  the  environment  in  which 
we,  as  government  program  managers,  must  manage  and  resolve  daily  issues.  Therefore, 
program  managers  need  to  have  an  appreciation  of  the  fundamental  concepts  involved  in 
the  acquisition  process.  The  following  discussion  involves  some  of  basic  information 
necessary  to  understand  the  environment  in  which  program  managers  must  manage  their 
systems. 

The  basis  for  the  program  manager’s  authority  is  DODD  5000.1  and  DODI  5000.2 
as  implemented  by  AFR  800-2.  DODD  5000.1  really  is  the  document  that  lays  the  foun¬ 
dation  governing  the  DOD  acquisition  process.  It  provides  the  philosophy  on  which  pro¬ 
gram  managers  make  decisions  and  explains  why  weapon  systems  move  from  one  phase 
to  another.  DODI  5000.2,  on-the-other-hand,  supplements  DODD  5000.1  providing  the 
process  to  carry  out  the  ground-rules  established  in  DODD  5000.1.  These  ground-rules 
and  policy  apply  across  the  DOD.  The  Air  Force  implements  and  applies  the  concepts 
through  AFR  800-2,  Acquisition  Program  Management,  which  is  applicable  and  manda¬ 
tory  policy  for  all  persons  involved  in  acquisition  programs  and  major  modifications. 
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As  program  managers  receive  program  direction,  based  on  the  guidelines  in  AFR 
800-2,  they  must  constantly  weigh  what  needs  to  be  done  in  the  program  versus  what 
can  be  done.  As  direction  flows  down  from  higher  headquarters,  program  managers  need 
to  be  informed  of  what  is  required  and  expected  of  their  weapon  system.  Two  critical 
documents  that  provide  program  direction  are  the  Program  Management  Directive 
(. PMD )  and  AFSC  Form  56.  The  PMD  is  normally  issued  from  the  HQ  USAF  level  to 
the  MAJCOM  level.  The  PMD  contains  important  information  with  regard  to  the  pro¬ 
gram  schedule  and  milestones,  program  participants,  funding  levels,  the  overall  require¬ 
ments  that  need  to  be  met,  and  just  about  anything  that  is  important  to  know.  The 
PMD  becomes  an  attachment  to  the  Acquisition  Decision  Memorandum  ( ADM)  which 
documents  the  Secretary  of  Defense’s  decision  to  approve/disapprove  the  program.  The 
PMD  is  used  during  the  entire  acquisition  cycle  to  state  requirements,  request  studies, 
and  initiate,  approve,  change,  transition,  modify,  or  terminate  programs.  The  content  of 
the  PMD,  including  required  review  and  approval  actions,  is  tailored  to  the  needs  of  each 
individual  program.  The  AFSC  Form  56  is  supplemental  tasking  that  flows  down  from 
HQ  AFSC  to  the  Product  Divisions.  Program  Managers  also  are  accountable  for  objec¬ 
tives  identified  in  a  baseline  agreement  with  the  Defense  Acquisition  Executive  (DAE). 
Together  with  the  DAE/Program  Manager  Baseline,  AFSC  Form  56,  and  Program 
Manager’s  charter,  the  PMD  defines  the  Program  Manager’s  specific  responsibility, 
authority,  and  accountability  for  attaining  program  objectives. 

REPORTING  PROCESS 

Performance  reviews  are  required  in  the  chain-of-command  for  resolution  of  major 
issues,  milestone  review,  program  changes  and  updates,  and  informational  purposes.  The 
type  of  review  is  dependent  on  the  point  of  origin  of  the  requesting  office  that  generated 
the  need  for  the  review.  Consequently,  the  type  of  review  that  program  managers  are 
typically  exposed  to  is  dependent  on  the  level  which  the  review  is  going  to  be  presented. 
There  are  basically  four  reviews  identified  here,  but  these  are  not  all-inclusive:  the 
Management  Assessment  Review  (MAR),  Command  Assessment  Review  (CAR),  Secre¬ 
tary  of  the  Air  Force  Program  Assessment  Review  (SAFPAR),  and  Selected  Acquisition 
Report  (SAR).  These  reviews  are  for  problem  identification.  The  following  is  a 
simplified  list  of  the  purpose  and  command  level  of  each  review: 

MAR  —  Each  program  management  area,  such  as  system  performance, 
schedule,  test  and  evaluation,  contracts,  and  so  forth  is  rated  either  satisfac¬ 
tory,  marginal,  or  unsatisfactory  in  a  briefing  that  is  reviewed  at  the  product 
division  level.  Major  problems  are  briefed  at  Headquarters  Air  Force  Systems 
Command  (HQ  AFSC). 

CAR  --  The  CAR  essentially  identifies  and  defines  specific  progress  versus 
plan  and  potential /current  problems  by  presenting  key  facts  and  information 
to  decision  makers.  The  CAR  is  reviewed  at  the  HQ  AFSC  level. 

SAFPAR  —  The  SAFPAR  is  an  in-depth  evaluation  mechanism  for  selected 
programs.  SAFPAR’s  are  conducted  on  a  quarterly  or  semi-annual  basis. 
SAFPAR  programs  are  selected  by  the  Secretary  of  the  Air  Force. 

SAR  —  The  SAR  provides  a  summary  of  key  cost,  schedule  and  technical 
information  on  these  types  of  DOD  acquisition  programs: 
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a.  All  programs  designated  as  major  systems  under  DODD  5000.1  and 
DODI  5000.2. 

b.  Any  program  Congress  designates. 

SARs  are  submitted  annually  as  of  December  31  and  must  reflect  the  President  s 
Budget.  Quarterly  submissions  are  required  when: 

a.  There  has  been  a  5%  or  greater  change  in  total  program  costs. 

b.  There  has  been  a  3%  or  greater  delay  in  the  current  estimate  of  any 
schedule  milestone. 

c.  Corrections  to  variance  calculations  and  adjustments  have  been 
approved  by  the  Assistant  Secretary  of  Defense  (Comptroller). 

By  comparing  current  estimates  with  established  baselines,  the  report  provides 
consistent,  reliable  information  on  program  status.  This  information  relates  to  cost,  test 
and  evaluation  data,  future  production  deliveries,  characteristics  and  contract  data  indi¬ 
cating  contractor  and  award  data,  or  any  other  area  requiring  justification.  While  most 
major  programs  submit  the  SAR,  all  program  managers  should  understand  its  contents 
and  procedures.  Many  staffers  use  the  SAR  format  for  discussing  programs  with  the 
DOD  and,  expect  program  managers  to  be  able  to  converse  in  SAR  language. 

ACQUISITION  COMMANDS 

The  Air  Force  assigns  specific  responsibilities  to  commands  involved  in  the  acquisi¬ 
tion  of  weapon  systems.  These  responsibilities  are  explained  and  implemented  in  AFR 
800-2.  The  following  list  describes  these  commands  and  their  respective  responsibilities: 

Implementing  Command  —  The  implementing  command,  usually  HQ  AFSC: 

a.  Performs  tasks  defined  in  the  PMD. 

b.  Appoints  a  program  manager  and  establishes  a  program  office. 

c.  Establishes  procedures  for  developing  and  approving  the  program  acquisi¬ 
tion  strategy. 

d.  Delegates  program  management  authority  and  responsibility  to  the  pro¬ 
gram  manager  through  a  program  manager’s  charter. 

e.  Through  a  program  manager’s  charter,  provides  each  program  manager 
direction  for  each  assigned  system  or  discrete  project  or  task.  Sets  forth  in  the 
charter: 

(1)  The  relationship  between  the  program  manager  and  participating 
commands. 

(2)  Management  and  resource  threshholds  that  define  the  program 
manager’s  latitude  for  management  action  and  a  commitment  to  provide  all 
further  direction  by  a  PMD  and  supplemental  direction. 

(3)  Other  items  deemed  significant  by  the  Program  Executive  Officer 
{PEO). 

Participating  Command  --  The  participating  commands: 

a.  Provide  support  and  take  part  in  carrying  out  the  assigned  tasks 
of  the  PMD  and  other  program  documentation. 

b.  Accomplish  the  fiscal  planning  and  coordinate  plans  with  other 
participating  commands  to  identify  the  budgeting  and  funding  to 
support  assigned  program  tasks. 


3-6 


c.  Designate  staff  focal  points  that  are  commensurate  with  command 
involvement. 

Supporting  Command  —  The  supporting  command,  usually  Headquarters  Air  Force 
Logistics  Command  (HQ  AFLC): 

a.  Assists  the  program  manager  in  planning  and  conducting  the  integrated 
logistic  support  program. 

b.  With  the  implementing  and  operating  commands,  develops,  analyzes, 
and  reviews  support  requirements,  supportability  considerations,  affordability, 
and  logistics  support  alternatives  and  requirements. 

c.  Plans  for  the  transfer  of  program  management  responsibility  (AFR 
800-4). 

d.  For  the  operating  command,  develops  the  Depot  Support  Requirements 
Document  ( DSRD ).  The  DSRD  will  be  an  adjunct  to  the  System  Operational 
Requirements  Document  ( SORD )  (AFR  57-1). 

Responsibilities  of  Air  Training  Command  (HQ  ATC)  —  As  a  participating  command, 
HQ  ATC  helps  the  implementing,  operating,  and  supporting  commands: 

a.  Define  training  concepts. 

b.  Identify  training  requirements. 

c.  Assess  costs  and  risks  associated  with  training  program  alternatives. 

d.  Determine  milestone  schedules  for  developing  planned  training  capabili¬ 
ties. 

e.  Per  AFR  80-14,  take  part  in  test  and  evaluation. 

Responsibilities  of  Headquarters  Air  Force  Operational  Test  and  Evaluation  Center  (HQ 
AFOTEC)  —  As  a  participating  command,  HQ  AFOTEC: 

a.  Per  AFR  80-14,  manages  the  operational  test  and  evaluation  ( OT&E ) 
program. 

b.  Recommends  to  the  Defense  Acquisition  Executive,  Air  Force  Acquisi¬ 
tion  Executive,  and,  PEO  the  extent  of  HQ  AFOTEC,  supporting,  and  operat¬ 
ing  command  involvement  in  OT&E  programs. 

c.  Identifies  the  training  requirements  for  test  team  personnel. 

Operating  Command  —  As  a  participating  command,  the  operating  command: 

a.  Develops  the  SORD  for  the  preferred  alternative  candidate  solution 
recommended  for  a  Milestone  I  review.  A  SORD  is  mandatory  for  all 
major  and  Air  Force  Designated  Acquisition  Programs  ( AFDAP ). 

b.  Refines  and  expands  the  SORD  for  the  candidate  solutions,  which 
were  validated  during  the  Demonstration/Validation  phase  and 
recommended  for  a  Milestone  II  (F ull  Scale  Development)  decision. 

c.  Develops  and  submits  operational  and  maintenance  concepts,  plans, 
and  requirements  before  each  program  milestone  decision  is  considered. 

d.  Identifies  training  requirements  to  HQ  ATC. 

The  role  of  the  Operating  Command,  or  user  of  the  weapon  system,  is  very  important  in 
the  acquisition  process.  The  AFSC  Commander  has  recently  reinforced  the  importance 
of  the  using  commands  in  the  AFSC  550  series  of  regulations.  The  basic  mission  of 
AFSC  is  to  support  the  using  commands.  To  accomplish  this,  we  must  be  close  to  our 
customers.  This  concept  must  permeate  our  management  of  programs,  our  testing  of 
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systems,  and  our  exploration  of  technologies. 

ACQUISITION  PARTICIPANTS 

Finally,  be  familiar  with  key  individuals  and  organizations  that  affect  the  acquisi¬ 
tion  of  weapon  systems.  The  following  are  just  a  few  that  could  greatly  influence  your 
program: 

Program  Element  Monitor  ( PEM)  -  A  very  important  acquisition  member  of  your 
SPO  is  the  PEM,  who  is  a  member  of  Air  Staff.  The  PEM  is  the  expert  everyone  turns 
to  for  any  and  all  information  concerning  his  program(s).  The  PEM  presides  over  a  pro¬ 
gram  from  the  pain  of  birth,  through  the  joy  of  growth  and  success,  and  possibly  t  he 
agony  of  death.  The  PEM  provides  the  corporate  memory ,  is  an  indispensable  link 
between  the  using  command(s)  and  the  Air  Staff,  and  is  the  program  spokesman  for  any¬ 
one,  anytime.  In  other  words,  the  PEM  is  the  primary  advocate  for  your  program.  To 
provide  care  and  feeling  for  his  programs,  the  PEM  prepares  and  updates  budget 
requests,  and  guidance  documents,  as  required.  The  PEM  also  reviews  Congressional  tes¬ 
timony,  answers  questions  for  the  record,  and  prepares  the  PMD.  The  bottom  line  is 
that  the  PEM  must  stay  constantly  alert  to  keep  abreast  of  what  is  a  very  fluid  situa¬ 
tion. 

System  Officer  ( SYSTO )  --  The  SYSTO  is  AFSC’s  equivalent  to  the  PEM.  The 
SYSTO  performs  some  of  the  same  functions  as  the  PEM  but  at  a  different  level  --  HQ 
AFSC.  The  SYSTO  is  the  officer  who  is  the  focal  point  for  staff  actions  associated  with 
a  particular  program  (per  AFSCR  800-1).  The  SYSTO  updates  periodic  briefings  like 
the  SAFPAR  at  the  HQ  AFSC  level. 

General  Accounting  Office  (GAO)  -  The  GAO  is  an  agency  in  the  legislative 
branch  of  the  government  and  is  considered  the  audit  or  oversight  agency  of  the 
Congress.  It  is  headed  by  the  Comptroller  General  of  the  United  States.  The  GAO  will 
assist  the  Congress  by: 

a.  Providing  information,  services,  facilities,  and  personnel  to  the 
Congressional  Budget  Office. 

b.  Assisting  congressional  committees  in  developing  statements  of 
legislative  objectives,  goals,  and  methods  for  assessing  and  reporting 
program  performance. 

c.  Assisting  committees  in  analyzing  and  assessing  federal  agency  program 
reviews  and  evaluation  studies. 

Air  Force  Plant  Representative  Officer  (APPRO)  —  The  AFPRO  is  the  Air  Force 
representative  physically  located  at  the  contractor’s  facility.  Consequently,  the  AFPRO 
is  a  rich  source  of  information  concerning  many  aspects  of  your  program.  They  should 
know  the  contractor’s  business  environment,  since  they  are  right  there.  AFPROs  can 
provide  current  wage  rates,  contractor  performance,  learning  curve  rates,  past  history  on 
similar  programs,  program  tasks  and  their  status  with  the  contractor,  and  just  about 
anything  else  related  to  the  contractor’s  performance. 

Other  participants  —  Other  participants  include  those  federal  agencies  who  might 
have  a  vested  interest  in  your  program.  These  participants  include  organizations  that 
have  similar  goals  and  objectives  as  your  program.  For  instance,  if  your  program 
involves  joint  service  usage  with  the  Army,  Navy,  and/or  Marine  Corps,  they  would  be 
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major  actors  in  the  acquisition  of  your  weapon  system.  If  your  program  is  to  be 
deployed  in  space,  the  National  Aerospace  and  Space  Administration  might  be  involved 
in  your  program.  The  Federal  Aviation  Administration  might  have  inputs  with  regard 
to  the  safety  of  certain  weapon  systems  being  deployed  in  the  continental  United  States. 
As  you  can  guess,  the  list  does  not  stop  here.  As  program  manager,  you  may  have  a 
myriad  of  organizations  throughout  the  DOD  to  deal  with  during  an  acquisition  life 
cycle. 
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PROGRAM  MANAGERS  AUTHORITY 


SOURCE:  AFR  800-2 

DODD  5000.  1 
DODI  5000.2 

DEFINITION:  SINGLE  AF  MANAGER  RESPONSIBLE  FOR 

ACQUIRING  AND  FIELDING  A  SYSTEM 
THAT  MEETS  THE  APPROVED  MISSION 
NEED  AND  ACHIEVES  THE  ESTABLISHED. 

0  COST  GOALS 

0  SCHEDULED  GOALS 

0  PERFORMANCE  GOALS 

0  LOGISTICS  SUPPORT  GOALS 
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FLOW  OF  DIRECTION 


USAF 


PROGRAM  MANAGEMENT  DIRECTIVE  ( PMD ) 


AFSC 


AFSC  FORM  56 


PRODUCT  DIVISION 


PROGRAM  MANAGER  CHARTER 


SYSTEM  PROGRAM  OFFICE 


PROGRAM  MANAGEMENT  PLAN 

o'  cf  o' 

PARTICIPATING  COMMANDS 


*** 

PRIMARY  CONCERNS  OF  PROGRAM  MANAGER 

0  PLAN  TO  IMPLEMENT  DIRECTED  PROGRAM 

0  IDENTIFY  AND  OBTAIN  RESOURCES 

*  PEOPLE 

*  MONEY 

0  DETERMINE  STATUS 

0  ADJUST  PLANNING 
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FLOW  OF  REPORTING 


IMPLEMENTING  COMMAND 


THE  COMMAND  CHARGED  WITH  PRIMARY 
RESPONSIBILITY  FOR  DEVELOPING  AND 
ACQUIRING  THE  SYSTEM  OR  EQUIPMENT 


*** 


SUPPORTING  COMMAND 


COMMAND  CHARGED  WITH  RESPONSIBILITY  FOR 
PROVIDING  LOGISTICS  SUPPORT  AND  DESIGNATED 
TO  ASSUME  PROGRAM  MANAGEMENT  RESPONSIBILITY 
FROM  THE  IMPLEMENTING  COMMAND. 

*  *  * 


OPERATING  COMMAND 


THE  COMMAND  OR  AGENCY  PRIMARILY  RESPONSIBLE 
FOR  THE  OPERATIONAL  EMPLOYMENT  OF  A  SYSTEM, 
SUBSYSTEM  OR  ITEM  OF  EQUIPMENT 

*** 


PARTICIPATING  COMMAND 


A  COMMAND  OR  AGENCY  DESIGNATED  BY  HQ  USAF 
PROGRAM  MANAGEMENT  DIRECTIVE  (PMD)  TO  SUPPORT 
AND  ADVISE  THE  IMPLEMENTING  COMMAND  DURING  A 
DEVELOPMENT  OR  ACQUISITION  PROGRAM 

*** 


HQ  AFSC  PLAYERS 


0  PROGRAM  ELEMENT  MONITOR  (PEM) 

0  SYSTEMS  OFFICER  (SYSTO) 

0  PROGRAM  MANAGEMENT  ASSISTANCE  GROUP 
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LESSON  4 


LESSON  TITLE:  Acquisition  Process 
TIME:  2.5  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  management  concepts  and  decision  process  which  governs  the 
acquisition  of  Air  Force  systems  and  equipment. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  State  the  philosophy  of  the  Air  Force  in  the  following  areas: 

(1)  The  single  point  manager 

(2)  Incremental  resource  allocation 

(3)  Competition. 

b.  Describe  the  process  of  a  DOD  major  program  initiation. 

c.  List  the  purpose  of  and  activities  that  occur  during  the  following  life 
cycle  phases: 

(1)  Concept  Exploration/Definition 

(2)  Concept  Demonstration  and  Validation 

(3)  Full-Scale  Development 

(4)  Production  and  Deployment 

(5)  Operational  Support. 

d.  Identify  the  following  milestones,  the  level  of  decisions,  and  their 
relationship  to  the  phases  of  the  acquisition  life  cycle: 

(1)  Mission  Need  Determination  (Milestone  0) 

(2)  Milestone  I 

(3)  Milestone  II 

(4)  Milestone  III 

(5)  Milestone  IV 

(6)  Milestone  V. 

e.  State  how  the  decision  process  differs  between  a  DOD  Major  program  and  a 
Non-Major  program. 

f.  List  the  objectives  and  goals  of  the  Reliability  and  Maintainability 
(R  &  M  2000)  program. 

TOPIC  INTRODUCTION: 

With  the  information  you  have  assimilated  so  far  about  the  acquisition  of  weapon 
systems,  nothing  is  more  important  than  understanding  the  life-cycle  of  the  acquisition 
process.  You,  as  the  program  manager,  need  to  understand  where  your  program  fits  into 
the  acquisition  life  cycle.  For  example,  your  program  may  be  in  the  Concept 
Exploration/Definition  phase,  where  ideas  are  being  generated  on  how  to  meet  the  mis¬ 
sion  need,  or  your  program  might  be  starting  out  in  the  Production  phase,  where  there  is 
no  requirement  for  Concept  Exploration/Definition,  Concept  Demonstration  and  Valida¬ 
tion  or  Full-Scale  Development.  (This  was  the  case  of  the  Air  National  Guard’s  Air 
Defense  Fighter,  where  the  PMD  stated  you  will  buy  a  fighter  where  no  development  is 
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required.)  The  Air  Force  philosophy  on  program  management  stems  from  the  concept  of 
one  person  being  responsible,  at  all  times,  for  the  program  in  satisfying  user  and  acquisi¬ 
tion  requirements,  budget  constraints  (more  on  budget  in  lesson  5),  and  iterative  mile¬ 
stones  and  reviews.  These  milestones  and  reviews,  in  the  acquisition  life-cycle,  are  noth¬ 
ing  more  than  decision  points,  taking  a  program  in  an  orderly  progression  from  an 
identification  of  system  need  to  final  operational  deployment.  In  doing  this,  each  pro¬ 
gram  manager  must  tailor  their  approach  to  maximize  use  of  the  resources  available. 
One  of  the  program  manager’s  goals  in  the  acquisition  process  is  to  ensure  that  weapon 
systems  are  reliable  and  maintainable,  once  deployed;  consequently,  that  reliability  ami 
maintainability  planning  is  done  early  enough  in  the  program’s  development. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  The  Acquisition  of  Major  Systems,  by  Mr  McCarty,  AFIT/LSY 
(Same  as  lesson  1) 

b.  Article,  Air  Force  Reliability  and  Maintainability  Program, 

USAF  Fact  Sheet  85-27 

c.  Acquisition  Process  videotapes 

d.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4”  tape  player 
REFERENCES: 

a.  DOD  Directive  5000.1,  Major  System  Acquisition 

b.  AFR  800-2,  Acquisition  Program  Management 

c.  AFR  800-19,  System/ Equipment  Turnover 

d.  AFR  800-4,  Transfer  of  Program  Management  Responsibility 

e.  AFSCP  800-3,  A  Guide  for  Program  Management 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  The  Acquisition  of  Major  Systems 

b.  Read  article:  Air  Force  Reliability  and  Maintainability  Program 

c.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  Briefly  discuss  the  key  functions  to  be  performed  in  each  of  the  five  phases  of  the 
acquisition  process. 
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2.  Describe  the  acquisition  problems  and  solutions  of  the  1970’s  with  the  problems 
and  solutions  of  the  1980s. 


3.  Briefly  discuss  the  main  thrust  of  the  Packard  Commission  recommendations 
that  will  impact  the  acquisition  process  in  the  1980s  and  1990s. 


4.  Briefly  discuss  how  Reliability  and  Maintainability  goals  and  objectives  relate  to 
the  acquisition  process. 

[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 


See  Lesson  #  1  Acronyms,  since  the  reading  for  Lesson  #  4  is  the  same. 
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United  States  Air  Force 

Secretary  of  the  Air  Force.  0*ce  of  Public  Alairs.  Washington.  D  C  20330 
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Air  Force  Reliability  and  Maintainability  Program 


The  Air  Force  Reliability  and  Maintain¬ 
ability  (RAM  2000)  Program  was  developed  by 
direction  of  the  secretary  of  the  Air  Force  and 
chief  of  staff  of  the  Air  Force  to 
institutionalize  the  Air  Force's  commitment  to 
improving  reliability  and  maintainability  of 
weapon  systems.  Reliability  and 

maintainability  must  be  coegual  with  cost, 
schedule  and  performance  factors  as  the  Air 
Force  brings  new  systems  into  the  inventory 
and  modifies  its  existing  systems.  The  RAM 
2000  program,  which  is  managed  by  the  special 
assistant  for  reliability  and  maintainability 
assigned  to  the  Directorates  of  Logistics  and 
Engineering,  and  Research,  Development  and 
Acquisition  at  Headquarters  U.S.  Air  Force, 
The  Air  Force  requires  improved  reliability 
and  maintainability  of  both  new  and  fielded 
weapon  systems.  To  achieve  this,  the  Air 
Force  is  stepping  up  its  search  for  basic 
system  changes  that  will  ensure  the  most 
reliable,  maintainable  systems  possible  for  the 
dollar  invested.  Reliability  and  maintain¬ 
ability  are  means  to  an  end,  and  that 


end  is  combat  capability.  Reliable  systems 
reduce  the  ownership  costs  of  systems,  reduce 
the  system's  dependence  on  spare  parts, 
require  fewer  combat  support  people  and 
result  in  more  missions  per  deployed  system. 
If  systems  are  more  maintainable,  fewer 
people  with  highly  specialized  diagnostic  skills 
are  needed  and  maintenance  times  to  repair 
systems  are  reduced. 

Equally  important,  reliability  and 
maintainability  improve  the  mobility  of  the 
forces  because  of  the  reduced  need  to  deploy 
maintenance  people  and  support  equipment. 
Improved  reliability  and  maintainability  ir 
current  and  future  systems  will  provide  tl 
Air  Force  significant  increases  in  combo 
capability. 

Reliability  and  Maintainability  Explained 

The  terms  reliability  and  maintainability 
are  related  but  separate.  The  distinction 
should  be  understood. 

Reliability  is  officially  defined  as  the 
probability  that  an  item  will  perform  its 
intended  function  for  a  specified  interval 
under  stated  conditions.  In  the  simplest  sense, 
reliability  means  how  long  an  item  (such  as  a 
machine)  will  perform  its  intended  function 
without  a  breakdown.  For  example,  if  your 
car  runs  well  and  never  breaks  down,  it  is 
highly  reliable.  A  reliable  car,  like  a  reliable 
aircraft,  does  not  have  to  go  to  the  repair  shop 
very  often. 

When  it  does  break  down,  how  difficult  is  it 
to  troubleshoot  and  repair?  That  introduces 
the  concept  of  maintainability.  Maintain¬ 
ability  is  defined,  officially,  as  the 
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ability  of  an  item  to  be  retained  in,  or 
restored  to,  specified  condition  when 
maintenance  is  performed  by  people  having 
specified  skill  levels,  using  prescribed 
procedures  and  resources.  Early  mass- 
produced  cars  were  simple  and  easy  to  repair 
--  very  maintainable  --  but  not  very  reliable; 
they  broke  down  too  often.  Modern  aircraft, 
like  late  model  cars,  are  much  more  complex. 
When  they  break  down,  they  are  more  difficult 
to  repair  and  it  takes  highly  skilled  mechanics 
to  repair  them. 

The  challenge  of  the  Air  Force  Reliability 
and  Maintainability  (RAM  2000)  Program  is  to 
ensure  eguipment  and  systems  designs  promote 
reliability  --  operate  long  and  well  between 
breakdowns;  and  is  maintainable  —  repaired 
easily  and  efficiently  by  people  trained  to 
reasonable  skill  levels  using  practical  tools. 

Objectives 

The  objectives  of  the  RAM  2000  program 
a  to: 

Provide  clear  direction  aimed  at  increasing 
.-liability  and  maintainability  of  Air  Force 
systems  to  increase  weapon  system  combat 
effectiveness. 

•  Focus  organizational  attention  and  expand 
training  to  build  the  reliability  and  maintain¬ 
ability  technical  expertise,  advocacy, 
authority  and  accountability  throughout  the 
Air  Force. 

•  Improve  reliability  and  maintainability 
planning  to  consolidate  efforts,  tie  reliability 
and  maintainability  to  operational  goals,  and 
coordinate  major  command  efforts  to 
accelerate  improvements  in  weapon  system 
reliability  and  maintainability. 

•  Establish  internal  administrative  systems 
in  order  to  ensure  effective  accountability  and 
feedback  to  measure  progress  in  the  reliability 
and  maintainability  improvement  program. 

•  Provide  positive  communications  and 
motivation  to  sustain  commitment  to  and 
support  for  reliability  and  maintainability 
goals. 

•  Obtain  and  sustain  industry  commitment  to 
'tsure  that  contractors  have  the  motivation 

1  capability  to  support  reliability  and  main- 
. (inability  requirements. 


Goals 

The  Air  Force  has  set  five  goals  to  achieve 
the  objectives  of  the  RAM  2000  plan.  The 
achievement  of  these  goals  requires 
institutional  commitment  to  reliability  and 
maintainability  in  the  Air  Force  weapon 
systems.  These  goals  are: 

•  Increase  warfighting  capability, 
a  Increase  survivability  of  the  combat 
support  structure. 

a  Decrease  mobility  requirements  per 
deploying  unit. 

a  Decrease  manpower  requirements  per  unit 
of  output, 
a  Decrease  costs. 

Increase  Warfighting  Capability 

The  U.S.  Air  Force  will  measure  increased 
warfighting  capability  for  each  of  its  many 
different  kinds  of  weapon  systems.  For 
aircraft  warfighting  capability,  for  example, 
improvements  are  expected  in  the  number  of 
consecutive  missions  a  system  is  capable  of 
flying  in  combat  without  requiring 
maintenance  other  than  refuelinq  and 
reloading  ordinance.  The  future  advanced 
tactical  fighter  of  the  1990s  will  be  designed 
to  operate  at  a  sustained  sortie  rate  at  least 
twice  that  of  the  F-15  Eagle. 

Increase  Survivability  of  the  Combat  Support 
Structure 

Many  current  Air  Force  systems  are 
dependent  on  large  combat  support  facilities 
which  are  vulnerable  to  attack  and  destruction 
under  combat  conditions.  The  key  to 
increased  survivability  is  to  reduce 
dependence  on  vulnerable  fixed  operating 
bases.  One  way  to  do  this  is  to  make  use  of 
technological  advances  that  will  reduce 
dependence  on  complex  maintenance  facilities 
such  as  the  avionics  intermediate  shop  needed 
to  support  such  systems  as  the  F-15  and  F-16 
Fighting  Falcon.  The  design  of  more 
maintainable  systems  is  absolutely  essential  to 
attain  the  necessary  improvements  in  the  Air 
F  orce  combat  capability  for  the  1990s. 
Reducing  the  need  for  sophisticated  and 
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complex  test  equipment  like  the  avionics 
intermediate  shop  means  that  fewer  combat 
support  people  and  highly  trained  maintenance 
specialists  would  be  placed  "in  harms  way" 
during  a  conflict. 

Decrease  Mobility  Requirements  Per 
Deploying  Unit 

Through  reliability  and  maintainability 
improvements,  such  as  Air  Force  fighter  air¬ 
craft  with  buitt-in  test  and  on-board  fault 
detection  and  isolation  system,  fewer  main¬ 
tenance  people  and  less  support  equipment 
would  be  needed  in  a  combat  zone.  Presently 
more  than  five  C-141B  Starlifters  are  needed 
to  airlift  an  avionics  intermediate  shop  for  a 
deploying  squadron  of  F-15s.  It  now  takes 
about  18  C-141B  aircraft  leads  (equivalent)  to 
deploy  an  F-15  squadron. 

By  reducing  dependence  on  an  avionics 
intermediate  shop  through  improvements  in 
the  avionics  system,  the  Air  Force  could 
deploy  four  squadrons  of  F-15s  with  the  same 
airlift  required  to  deploy  three  squadrons 
today. 

Decrease  Manpower  Requirements  Per  Unit  of 
Output 

Gains  in  reliability  and  maintainability 
translate  directly  into  increased  productivity 
for  the  highly  trained,  highly  skilled 
technicians  needed  to  maintain  today's 
aerospace  systems.  Air  Force  people  are  a 
constrained  resource  which  must  be  considered 
during  the  earliest  design  stages  of  weapon 
systems. 

Maintenance  people  require  training, 
shelters,  chemical,  biological  and  radiological 
protection,  and  other  combat  support 
activities  to  provide  for  their  well-being.  The 
combat  support  activities  require  personnel 
support  themselves. 

Reliability  and  maintainability  improve¬ 
ments  will  provide  the  Air  Force  with  the 
opportunity  to  reduce  dependence  on  combat 
support  people  in  future  systems,  and  the 
potential  to  reallocate  already  constrained 
people  resources  into  priority  Air  F  orce 
activities. 


Decrease  Costs 

The  decrease  in  costs  through  improved 
reliability  and  maintainability  would  come 
from  savings  in  areas  such  as  acquisition  costs, 
operating  and  support  costs,  manpower,  train¬ 
ing  and  spare  parts  costs.  These  reliability 
and  maintainability  savings  can  be  reinvested 
in  other  Air  Force  modernization  efforts. 

F  or  example,  the  Air  F  orce  manages 
approximately  8^t,,n00  different  types  of  spare 
parts.  1  he  parts  invent orv  is  worth  more  than 
hillion.  In  fiscal  the  budget 

contained  more  than  $f>  billion  for  spares. 
Management  of  spare  parts  involves  a  highly 
complex  system  that  employs  hundreds  of 
thousands  of  people.  Consequently  the  higher 
the  reliability  of  Air  Force  systems,  the 
smaller  the  requirement  for  spare  parts  and 
the  greater  potential  for  savings. 

Accomplishments 

Recently  the  Air  Force  decided  not  to 
proceed  with  a  $250  million  dollar  program  for 
radar  warning  receivers.  While  a  new  rada 
warning  receiver  is  badly  needed  to  replace 
the  current  one,  the  proposed  system  did  not 
offer  significant  reliability  and  maintainability 
increases  over  the  one  already  fielded.  The 
Air  Force  stopped  the  program  and  is  now  re¬ 
competing  the  procurement  of  a  new  radar 
warning  receiver. 

Low-Altitude  Navigation  and  Targeting 
Infrared  System  for  Night  (LANTIRN)  is  one  of 
the  Air  Force's  highest  priority  programs 
designed  to  take  the  night  sanctuary  from  the 
enemy.  The  LANTIRN  navigation  pod  pro¬ 
curement  program  has  been  restructured  to 
ensure  the  Air  Force  obtains  a  system  which 
meets  not  only  performance  requirements,  but 
also  stringent  reliability  and  maintainability 
growth  goals.  The  goals  must  be  met  prior  to 
approval  of  each  successive  production  lot 
purchase.  Furthermore  the  reliability  and 
maintainability  goals  for  LANTIRN  are 
provided  for  under  a  firm  fixed  price  contract. 
The  Air  Force  will  go  no  further  with  a  new 
production  lot  until  the  reliability  goals  are 
achieved. 
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A  key  program  under  the  RAM  2000 
umbrella,  the  Blue  Two  Visit  proqram  contrib¬ 
utes  to  achieving  the  Air  Force  RAM  2000 
goals.  The  Blue  Two  visits  take  lead  design 
engineers  from  defense  contractors  to  the 
various  locations  where  their  equipment  or 
similar  systems  are  in  use  on  Air  Force  flight 
lines. 

The  term  "Blue  Two"  is  the  nickname  of 
the  Air  Force  men  and  women  who  must 
maintain  the  modern  weapon  systems  in  the 
Air  Force  inventory.  The  visits  are  intended 
to  show  the  design  engineers  what  the  real 
world  of  aircraft  maintenance  is  like. 

This  is  not  a  vacation  for  those  designers. 
They  go  out  to  the  flight  line  and  the 
maintenance  shops  where  the  life  line  of  Air 
Force  weapon  systems  is  sustained.  The 
engineers  see  operations  and  maintenance  of 
systems  first-hand  —  to  include  participating 
in  early  morning  and  late  night  mission 
launches  with  the  maintenance  force 
.  .  .  donning  chemical,  biological  and 
radiological  attire  —  to  work  on  the  systems 
they  may  have  had  a  hand  in  designing. 

The  Blue  Two  visits  permit  the  engineers 
to  observe  the  current  job  routines  of  Air 
Force  maintenance  people  ...  to  discuss  with 
those  military  and  civilian  maintenance  people 
what  they  find  frustrating  or  rewarding  with 
existing  equipment  ...  to  discover  problems 
encountered  with  overspecialization  in  tools, 
or  the  inability  to  use  tools  designed  in 
isolation  from  the  real  work  environment 
.  .  .  to  witness  where  the  dependencies  or 
interdependencies  occur  among  the 
maintenance  and  supply  activities  found  in  Air 
Force  sortie  generating  organizations.  The 
Blue  Two  visits  and  other  RAM  7000 
mil i: (lives  me  meelerol mg  improvements  to 
Air  I  oree  syst ems. 

Significant  improvements  to  Air  I  orce 
weapon  systems  have  been  made  in  recent 
years.  RAM  2000  will  increase  the  pace  of 
those  improvements.  Current  systems  are 
more  reliable  and  maintainable  than  the 
systems  they  replaced.  For  example,  the  F-15 
requires  only  85  percent  of  the  maintenance 
manhours  per  flying  hour  than  the  older  F-4 
Phantom  aircraft.  The  F-16  requires  only 


one-half  the  maintenance  manhours  per  flying 
hour  as  the  F  -A. 

For  cargo  aircraft,  the  Air  Force  expects 
the  C-17  to  require  less  than  one-half  the 
maintenance  manhours  per  flyinq  hour  of  the 
C-5A  Galaxy. 

The  maintenance  manhours  per  flying  hour 
are  significant  factors  since,  of  the  more  than 
485,000  enlisted  people  in  the  Air  Force  today, 
one  in  every  three  is  involved  in  maintaining 
aircraft.  Through  the  RAM  2000  proqram  and 
such  initiatives  as  the  Blue  Two  Visit  program, 
the  Air  F orce  expects  to  further  improve  the 
maintenance  requirements  of  both  new  and 
current  weapon  systems. 

Summary 

The  Air  Force  RAM  2000  goals  provide  the 
key  leverage  points  for  achieving  increased 
combat  capability;  increased  survivability  of 
the  combat  support  structure;  decreased 
mobility  requirements  per  deploying  unit; 
decreased  manpower  requirements  per  unit  of 
output;  and  decreased  costs.  Revising  the  way 
the  Air  F orce  views  reliability  and  maintain¬ 
ability  will  not  be  enough.  RAM  2000  is  a 
cultural  change  within  the  Air  Force  and 
defense  industry.  Reliability  and  maintain¬ 
ability  are  now  coequal  with  the  cost,  schedule 
and  performance  factors  associated  with  the 
acquisition  of  new  systems  and  modifications 
to  existing  systems. 

Reliable  and  maintainable  systems  are  not 
an  end  —  they  are  a  means  to  an  end  —  and 
that  end  is  increased  combat  capability.  The 
Air  Force  is  making  reliability  and  maintain¬ 
ability  in  new  systems  more  visible  throughout 
the  weapon  system  acquisition  process.  The 
Air  Force  is  demanding  from  itself,  and  the 
contractors  who  support  it,  accelerated 
improvements  in  the  reliability  and  maintain¬ 
ability  of  weapon  systems. 

The  payoff  from  these  and  other  improve¬ 
ments  in  reliability  and  maintainability  will  be 
enhanced  combat  capability  and  an  improved 
deterrent  posture  for  America's  "Arsenal  of 
Democracy." 
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THE  ACQUISITION  PROCESS 

LESSON  OVERVIEW 


-  ACQUISITION  GUIDANCE 

-  -  Single  Point  Manager 

--  Incremental  Resource  Allocation 

-  -  Competition 

--  Categories  of  Programs 

-  ACQUISITION  PHASES 

-  -  Purpose  and  Activities 

-  -  Milestone  Reviews 

-  -  Program  Documentation 


ACQUISITION  GUIDANCE 


OFFICE  OF  MANAGEMENT  AND  BUDGET 
CIRCULAR  A- 109 

♦  Applies  to  all  Federal  Executive 
Agencies 

*  Operational  Need  in  terms  of  Mission 

*  An  extensive  use  of  competition 
FLOW  DOWN  REGULATIONS 

•  DODD  5000.1/DODI  5000.2 


•  AFR  57-1 

*  AFR  800-2 
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THE'ACQUISITION  CYCLE 


ACQ  INITIATION  PROCESS 

*  MISSION  AREA  ANALYSIS 

*  STATEMENT  OF  OPERATIONAL  NEED 

*  BUDGET  COMPETITION 

*  PROGRAM  MANAGEMENT  DIRECTIVE 

*  FORM  5  6 /PAD 
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THE  ACQUISITION  CYCLE 


PHASE  I 

CONCEPT  EXPLORATION 

EXPLORE  Alternatives 

ESTIMATE  Cost,  Schedule,  Performance 
and  Logistics  Parameters  for  each 
Alternative 

System  Concept  Paper 
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DOD  MAJOR  PROGRAM 


*  Cost:  $200M  FY  80  R&D 

$1B  FY  80  PROD 

*  Joint  Service  Acquisition 

*  International  Program 

*  Congressional  Interest 

*  Sec  Def  Interest 


MILESTONE  I 


*  SYSTEM  CONCEPT  PAPER 

*  ISSUES 
Threat 

Weapon  Concept 
Risk 

Schedule 
Readiness 
Affordability 
Acquisition  Strategy 

*  NOT -TO -EXCEED  THRESHOLDS 

Concept  Validation 

Early  Full  Scale  Development 
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DEFENSE  ACQUISITION 

BOARD  (DAB) 


OSD  level  "corporate  vice 
presidents” 

Reviews  major  programs 

In  decision-making  process 

Recommends  to  SECDEF  -  approval 
to  enter  next  phase 

Does  not  provide  funds  or  vote 


SECRETARY  OF  DEFENSE 
DECISION  MEMORANDUM  (SDDM) 

DEFENSE  ACQUISITION  EXECUTIVE  (DAE) 
COORDINATES  AND  FORWARDS  TO  SEC 
FOR  DECISION 

MILESTONE  ’I”  SDDM  ESTABLISHES  WHEN 
NEXT  MILESTONE  SHALL  OCCUR 

UPON  APPROVAL,  DOD  COMPONENT  MAY 
NECESSARY  PROGRAMMING  ACTION  (PPB 

ESTABLISHES  PROGRAM  GOALS  AND 
THRESHOLDS 


fHE  ACQUISITION  CYCLE 


DEVELOPMENT  PHASE 


* 


PHASE  II 

DEMONSTRATION  /  VALIDATION 


*  BUILD  PROTOTYPES 

*  CONDUCT  COMPETITION 

*  REFINE  COST,  SCHEDULE,  PERFORMANCE 

and  LOGISTICS  PARAMETER  ESTIMATES 
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MILESTONE  II 


*  DECISION  COORDINATING  PAPER 

Need  Assessment 
Threat  Assessment 
Test  Results 
Risk  Assessment 
Acquisition  Strategy 

*  DECISION  BRIEFING 

*  REVISED  PMD 


PHASE  III 

FULL  SCALE  DEVELOPMENT 


*  DEVELOP  COMPLETE  SYSTEM 

Hardware 

Software 

Support  Equipment 
Technical  Orders 
Etc. 

*  CONDUCT  COMPREHENSIVE  TESTING 

*  PREPARE  FOR  PRODUCTION 
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MILESTONE  III 


*  UPDATED  DECISION  COORDINATING  PAPER 

Need  Assessment 
Threat  Assessment 
Test  Results 
Production  Readiness 

*  Decision  Briefing 

*  Updated  PMD 


PHASE  IV 
PRODUCTION 


*  PRODUCE  SYSTEM 

*  PRODUCE  the  SUPPORT  SYSTEM 

*  PROGRAM  MANAGEMENT  RESPONSIBILITY 
TRANSFER  (PMRT) 

*  FOLLOW-ON  OPERATIONAL  TEST  and 
EVALUATION 
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THE  ACQUISITION  CYCLE 


NEW  PROPOSED  MILESTONES 


MILESTONE  IV  REVIEW 

Post  Initial  Operational  Capability 

Actual  Performance 

Actual  Readiness  and  Supportability 


MILESTONE  V  REVIEW 

Current/Proj'ected  Requirements 
Major  Upgrades 
System  Replacement 
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LESSON  5 

LESSON  TITLE:  Planning,  Programming,  and  Budgeting  System  ( PPBS ) 

TIME:  3  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  process  by  which  USAF  and  DOD  programs  and  budgets  are  developed 
and  approved. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Describe  the  difference  between  planning,  programming,  and  budgeting 
efforts. 

b.  List  the  three  major  resources  defined  by  the  Five  Year  Defense  Program 
and  the  length  of  time  each  is  projected. 

c.  State  the  principle  phase  of  the  PPBS  to  which  the  following  documents 
relate: 

(1)  Joint  Strategic  Planning  Document  ( JSPD ) 

(2)  Program  Objective  Memorandum  ( POM) 

(3)  Budget  Estimate  Submission  ( BES ). 

d.  State  the  extent  to  which  changes  may  be  included  in  the  Budget 
Estimate  Submission. 

e.  Define  Authorization  and  Appropriation. 

f.  Identify  by  appropriation: 

(1)  obligation  life  span 

(2)  time  in  expired  status 

(3)  how  funds  are  identified  in  merged  accounts. 

TOPIC  INTRODUCTION: 

Planning,  Programming,  and  Budgeting  is  probably  one  of  the  least  understood 
areas  in  the  acquisition  arena.  It  is  also  one  of  the  most  publicized  topics  because  of  the 
annual  authorization  and  appropriation  process.  Recent  reform  legislation,  such  as  the 
Packard  Commission  Report,  highlight  the  need  for  budget  legislation  reform  and  to 
make  better  the  way  we  do  business.  As  a  program  manager,  you  need  to  understand 
what  planning,  programming,  and  budgeting  is  and  what  goes  into  the  Five  Year 
Defense  Program.  After  all,  if  you  have  program  direction  to  start  a  program  but  do  not 
have  budget  authority  (the  funds  necessary  to  carry  out  that  direction),  you  cannot 
aw’ard  the  contract.  This  lesson  introduces  the  structure  in  which  we  implement  budget 
requests,  and  the  documents  used  in  the  planning,  programming,  and  budgeting  process. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  Overmew  of  the  Planning,  Programming,  and  Budgeting  System , 
by  Mr  McCarty,  AFIT/LSY 
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b.  PPBS  videotapes 

c.  Lesson  viewgraphs 


AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  The  Planning,  Programming,  Budgeting  System  (PPBS)  -- 

A  Primer,  published  by  DCS/Programs  and  Resources,  HQ  USAF/PRP 

b.  DOD  Instruction  7045.7,  Implementation  of  the  Planning,  Programming, 
and  Budgeting  System  ( PPBS) 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Overview  of  the  Planning,  Programming,  and  Budgeting 
System 

b.  Scan  lesson  viewgraphs 
DISCUSSION  QUESTIONS: 

1.  As  an  OSD  staffer/programmer  whose  responsibility  encompasses  one  sector  of 
the  GUSTO  (Generally  Unified  Spheroid  Treaty  Organization)  defense  perimeter,  you 
find  references  to  numerous  and  varying  threats  in  the  official  planning  documents 
prepared  by  the  Joint  Staff.  These  threats  underlie  several  new  strategy  recommenda¬ 
tions.  Many  of  those  strategies  are  directly  applicable  to  your  area  of  concern.  Your  ini¬ 
tial  assessment  is  that  to  achieve  all  of  them  would  require  levels  of  research  and 
development;  weapons  procurements;  personnel  movement,  training,  and  "equippage"  far 
beyond  those  approved  in  past  budgets.  Your  most  recent  area  assessment  revealed  no 
major  or  unexpected  changes  in  enemy  activities  or  capabilities.  What  actions  would  you 
take  to'develop  your  recommendations  for  the  SECDEF’s  programming  guidance? 


2.  The  Five  Year  Defense  Program  ( FYDP )  identifies  resources  in  three  ways. 
What  are  those  resource  categories?  Which  resource  is  projected  for  more  than  five  years 
in  the  FYDP?  Why? 


3.  Discuss  why  the  POM  could  be  referred  to  as  the  "change  agent"  in  PPBS. 


4.  What  changes  (to  the  POM  submission)  may  be  made  in  the  Budget  Estimate 
Submission  (BBS)?  Give  an  example  and  explain  why  it  would  probably  be  an  accept¬ 
able  change. 
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5.  Discuss  the  differences  between  an  "authorization"  and  an  "appropriation." 
Which  allows  an  agency  to  obligate  government  funds? 


6.  Discuss  the  Gramm-Rudman-Rollings  deficit  limits  and  how  the  law  dictates  the 
achievement  of  spending  reductions. 


7.  Discuss  appropriation  "life  span"  and  what  happens  to 
'life  span"  is  complete? 


[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 
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DG  Defense  Guidance 

DNFYP  Department  of  the  Navy  Five  Year  Program 

DOD  Department  of  Defense 

DRB  Defense  Resources  Board 

IP  Issue  Paper 

JPAM  Joint  Program  Assessment  Memorandum 

JSPD  Joint  Strategic  Planning  Document 

OMB  Office  of  Management  and  Budget 

PDM  Program  Decision  Memorandum 


PLANNING,  PROGRAMMING  AND  BUDGETING  SYSTEM 

The  Planning,  Programming,  and  Budgeting  System  (PPBS)  used  in  the  DOD 
was  introduced  in  the  early  1980s  by  former  Secretary  of  Defense  McNamara.  The 
system’s  principle  purpose  was  to  institutionalize  planning  and  budgeting  functions  and 
to  add  a  new  function  -  programming  --  to  provide  a  bridge  between  planning  and 
budgeting.  The  PPBS  is  used  to  provide  a  Secretary  of  Defense-approved  Five  Year 
Defense  Program.  The  first  year  of  the  FYDP  is  the  budget  year.  Thus,  the  PPBS  also 
provides  DOD’s  input  to  the  formulation  phase  of  the  federal  budget,  process.  The  basic 
PPBS  has  withstood  the  test  of  time;  it  has  survived  as  the  resource  allocation  system 
under  various  secretaries  of  defense  in  both  Democratic  ami  Republican  administrations. 

Characteristics  of  the  FPBS: 

1.  Provides  the  structure  to  coordinate  a  wide  variety  of  management 
functions. 

2.  Serves  up  issues  for  decisions  and  records  those  decisions  as  they 
are  made. 

3.  Establishes  the  role  and  functions  of  the  principal  military  and 
civilian  authorities  in  building  the  DOD  budget. 

The  PPBS  Process 

The  PPBS  is  an  iterative  process  that  involves  three  separate  management  phases: 

A.  Planning.  Planning  involves  the  systematic  consideration  of  alternative 
actions  to  accomplish  DOD  objectives.  The  planning  function  provides  the 
framework  for  subsequent  DOD  programming  and  budgeting  actions  in  that  it 
is  primarily  goal  or  output  orientated.  The  objective  in  this  phase  is  to  iden¬ 
tify  strategies  and  capabilities  which  DOD  must  develop  in  order  to  support 
national  security  objectives. 

B.  Programming.  Programming  involves  a  review  of  the  capabilities  which 
DOD  must  develop,  and  subsequently  attempting  to  program  resources  to 
match  these  strategies.  The  programming  process  then  is  a  systematic  review 
and  consideration  of  the  currently  approved  programs  as  expressed  in  the 
FYDP.  However,  some  strategies  may  become  infeasible  when  resources  are 
considered.  As  a  result,  the  programming  process  may  involve  some  of  the 
same  activities  as  the  planning  process  as  priorities  may  have  to  be  changed  or 
strategies  modified. 

C.  Budgeting.  Budgeting  is  the  process  by  which  program  decisions  are 
translated  into  appropriations  requests.  Thus,  it  is  the  process  by  which  we 
identify  funding  requirements  for  Congressional  action.  As  with  programming, 
budgeting  is  a  function  which  sometimes  involves  elements  of  the  preceding 
functions.  As  budget  decisions  are  made,  it  may  be  necessary  to  reconsider 
strategies  previously  developed  or  to  reschedule  previously  approved  programs. 


Overview 

The  PPBS  cycle  is  the  sequence  of  events  used  to  accomplish  these  functions.  The 
cycle  is  based  on  a  calendar  which  provides  major  milestones  beginning  up  to  three  years 
prior  to  the  start  of  the  fiscal  year.  Because  this  cycle  consumes  more  than  two  years,  an 
odd-year/even-year  perspective  is  useful  in  developing  some  understanding  of  the  process. 

The  PPBS  cycle  includes  the  following  steps  and  data  in  arriving  at  a  DOD 
budget  submission: 

ODD-NUMBERED  YEAR 

Step  1:  Joint  Strategic  Planning  Document  ( JSPD ).  The  JSPD  provides  to  the  SECDEF 
a  statement  of  recommended  military  objectives  derived  from  national  objectives,  and 
the  recommended  military  strategy  required  to  attain  them.  Included  is  a  summary  of 
JCS  planning  force  levels  which  could  execute,  with  reasonable  assurance,  the  recom¬ 
mended  strategies.  Also  included  are  JCS  views  on  the  attainability  of  the  force  levels. 
The  JSPD  is  submitted  to  the  SECDEF  in  early  September  and  provides  foundation  for 
JCS  recommendations  on  force  planning  guidance  and  changes  to  the  DG. 

Step  2:  Defense  Guidance  {DG).  The  DG,  issued  by  the  SECDEF  in  December,  pro¬ 
vides  fundamental  policy,  strategy,  issues,  and  rationale  underlying  the  total  defense  pro¬ 
gram.  The  JCS,  Services,  and  Defense  agencies  receive  a  draft  DG  in  early  October.  It  is 
intended  that  a  dialogue  occur  between  the  Services,  the  JCS  and  the  OSD  staff  before 
the  issuance  of  the  final  version. 

EVEN-NUMBERED  YEAR 

Step  3:  Program  Objective  Memorandum  (POAf).  In  April  or  May  each  military  depart¬ 
ment  and  defense  agency  submits  a  POM  to  the  SECDEF.  The  POM  presents  a  priori¬ 
tized  program  and  includes  baseline  force  levels,  support  and  activity  levels,  and  deploy¬ 
ments  within  the  stated  constraints  and  fiscal  levels  of  the  DG.  The  POMs  will  include 
an  analysis  of  each  proposed  change  or  new  program.  They  express  force,  manpower, 
and  cost  implications  (FYDP  Update). 

Step  4:  Joint  Program  Assessment  Memorandum  (JPAM).  The  JPAM  provides  the 
views  of  the  JCS  on  the  adequacy  and  capabilities  of  the  total  forces  contained  in  the 
Service  POMs  to  execute  the  national  military  strategy,  and  the  risks  inherent  in  those 
force  capabilities.  The  JI’AM  includes  the  following: 

—An  assessment  of  the  capabilities  and  associated  risks  represented  by  the 
composite  POM  forces. 

—The  JCS  view  on  the  balance  of  the  recommended  Service  force  and  sup¬ 
port  levels. 

—JCS  recommendations  on  how  to  achieve  improved  defense  capabilities 
within  the  alternate  funding  levels  directed  by  the  SECDEF. 

—A  mobility  force  analysis. 
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Step  5:  Issue  Paper  (IP).  During  the  June-July  period  the  SECDEF  conducts  a  detailed 
review  of  the  Service  programs  and  makes  decisions  based  on  the  POMs  and  Issue 
Papers.  The  IPs  define  specific  issues  for  review  by  comparing  the  proposed  program 
with  the  objective  and  requirements  established  in  the  DG.  The  papers  present  alterna¬ 
tive  resolutions  for  each  issue  and  evaluate  the  merits  of  the  alternatives,  in  terms  of  the 
DG  fiscal  constraints,  and  their  ability  to  implement  the  missions  set  forth  in  the  DG. 
Issue  Papers  are  prepared  in  the  following  categories: 

Nuclear  Forces 
Conventional  Forces 
Modernization 
Intelligence 
Manpower 

Logistics  and  Readiness 


Step  6:  Program  Decision  Memorandum  ( PDM ).  In  late  July  or  early  August  a  PDM  is 
issued  by  the  SECDEF  for  each  military  department  and  defense  agency.  These  PDMs 
summarize  the  initial  program  decisions  of  the  current  cycle  based  upon  a  review  of  the 
POMs,  JPAM,  and  IPs.  The  PDMs  are  strongly  influenced  by  the  deliberations,  recom¬ 
mendations,  and  decisions  of  the  Defense  Resources  Board  (DRB).  They  constitute 
budget  guidance  to  the  recipient  organizations. 


Step  7:  Budget  Estimates.  In  mid-September,  each  military  department  and  defense 
agency  submits  its  annual  budget  estimate  to  the  SECDEF.  The  estimates  are  based 
upon  the  approved  programs  reflected  in  the  POMs  and  PDMs.  Specific  detailed  instruc¬ 
tions  for  budget  submissions  are  prescribed  by  OSD.  Upon  receipt  of  the  budget  esti¬ 
mates,  the  SECDEF  directs  a  review  by  the  OSD  staff  working  with  representatives  of 

wac  Mintc  oi  av Actiia^cnACiU/  anu  uuu^ct 


Step  8:  Budget  Decisions.  In  late  October  the  first  budget  decisions  will  be  issued. 
Departments,  JCS.  and  agencies  provide  comments  on  an  as  received  basis  in  order  that 
the  last  budget  decision  may  be  issued  by  mid-December.  Specific  budget  issues  that 
arise  may  result  in  major  issue  meetings  with  the  SECDEF. 


Step  9:  DOD  Budget  Submission.  Late  in  December  the  completed  DOD  budget  is  sent 
to  the  Office  of  Management  and  Budget  for  review  and  presidential  approval.  When 
approved  it  becomes  a  part  of  the  President’s  budget  submitted  to  the  Congress. 

Step  10:  The  President's  Budget.  In  January  of  each  year  the  President  submits  a 
Unified  Federal  Budget  to  the  Congress.  While  the  President  submits  an  annual  budget 
for  all  other  executive  branch  agencies,  the  DOD  submission  is  biennial  (January  of  the 
odd-numbered  years).  The  even-year  DOD  portion  of  the  President’s  Budget  requests 
necessary  budget  adjustments  to  the  second  year  of  the  DOD  submission  which  was 
made  the  previous  year. 
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The  Defense  Resources  Board  ( DRB ) 

The  Defense  Resources  Board  (DRB)  helps  the  SECDEF  manage  the  entire  PPBS. 
They  review  the  proposed  planning  guidance,  manage  the  program  and  budget  review 
process,  advise  on  PPB  major  issues  and  proposed  decisions,  and  assure  the  alignment  of 
major  system  acquisitions  with  available  resources.  DRB  members  represent  the  Services, 
the  JCS  and  OSD  staff  functions.  The  DEPSECDEF  is  the  Board  Chairman. 

The  Five  Year  Defense  Program  (FYDP) 

The  FYDP  is  comprised  of  ten  major  defense  programs  which  represents  the  mis¬ 
sion  and  support  responsibilities  of  the  DOD.  Each  major  defense  program  is  subdivided 
into  program  elements  whose  mission  characteristics  are  closely  related.  Programs  are 
structured  in  terms  of  both  mission  objectives  and  supporting  objectives.  Each  program 
therefore  consists  of  as  many  program  elements  as  necessary  to  provide  total  visibility  to 
the  mission  and  support  functions  of  the  program. 

The  FYDP  is  the  official,  formal  written  record  of  decisions  that  have  been  made 
in  DOD.  Its  purpose  is  clearly  defined  in  Department  of  Defense  (DOD)  Directive  7000.1. 
The  directive  states  that  the  FYDP  will  contain  DOD  approved  plans.  The  FYDP  is 
identified  as  the  nucleus  of  Department  of  Defense  resource  management  systems  and  sys¬ 
tems  developed  for  resource  management  will  be  consistent  with  it.  The  FYDP  is 
updated  during  the  PPBS  cycle  to  reflect  the  most  current  status  of  SECDEF  or 
Presidential  decisions. 

Thus,  the  FYDP  is  the  data  base  for  all  DOD  approved  plans,  and  its  language 
and  structure  provide  the  framework  for  DOD  resource  management.  The  FYDP  was 
developed  to  unify  forces  and  missions  and  to  be  useful  for  all  Military  Departments  and 
DOD  agencies.  The  FYDP  structure  is  aiso  used  to  develop  budget  estimates  based  on 
approved  forces  and  missions. 

The  following  discussion  explains  the  design  and  structure  of  the  Five  Year 
Defense  Program,  the  data  maintained  in  the  FYDP,  how  the  services  supplement  the 
FYDP,  and  how  the  FYDP  satisfies  the  original  criteria  for  its  design. 

Structure 

This  section  explains  how  the  Five  Year  Defense  Program  incorporates  data  on  the 
DOD  production  process,  including  outputs,  inputs,  and  processors. 

Outputs 

DOD  Directive  7000.1  emphasizes  that  the  Five  Year  Defense  Program  will  con¬ 
tain  Department  of  Defense  approved  plans.  When  organizations  engage  in  planning,  they 
are  looking  at  the  goals  or  objectives  of  the  organizations.  Goals  or  objectives  are  always 
expressed  in  terms  of  outputs.  Since  the  FYDP  was  to  contain  DOD  approved  plans,  its 
structure  had  to  include  output  information. 

Major  Force  Programs.  Major  Force  Programs  are  general  descriptions  of  DOD 
outputs.  FYDP  de  'gners  recognized  that  any  attempt  to  describe  DOD  outputs  with 
any  degree  of  precision  would  result  in  a  detailed  and  cumbersome  structure  which  would 
be  difficult  to  comprehend.  Additionally,  if  the  descriptions  were  too  specific,  it  would  be 
difficult  to  develop  a  presentation  which  unified  the  Military  departments  and  DOD 
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agencies.  Descriptions  thus  had  to  be  very  broad,  and  initially  nine  major  programs 
were  developed  to  describe  outputs.  Various  modification  have  led  to  the  current  struc¬ 
ture  of  ten  major  programs: 

1)  Strategic  Forces 

2)  General  Purpose  Forces 

3)  Intelligence  and  Communications 

4)  Airlift/Sealift 

5)  Guard  and  Reserve  Forces 

6)  Research  and  Development 

7)  Central  Supply  and  Maintenance 

8)  Training,  Medical,  and  Other  General  Personnel  Activities 

9)  Administration  and  Associated  Activities 

10)  Support  of  Other  Nations 

These  programs  are  general  enough  to  describe  activities  in  which  all  elements  of 
the  Department  of  Defense  are  involved,  yet  they  are  specific  enough  that  the  terms  are 
meaningful  to  FYDP  users.  For  example,  the  term  Strategic  Forces  would  invoke  images 
of  an  intercontinental  weapons  delivery  capability.  Within  this  major  program,  one 
would  expect  to  find  such  specific  capabilities  as  Air  Force’s  long-range  bombers  and 
intercontinental  missiles,  and  the  Navy’s  sea-based  missile  systems.  By  defining  outputs 
in  this  manner,  DOD  decision  makers  can  review  alternative  means  of  achieving  a  capa¬ 
bility  with  the  analysis  easily  able  to  cut  across  service  lines. 

Program  Elements.  Program  elements  are  subdivisions  of  Major  Force  Programs 
identifying  a  specific  capability.  While  the  Major  Force  Programs  are  useful  general 
descriptors  of  DOD  output,  it  was  recognized  that  decision  makers  would  need  specific 
information  on  the  weapons  systems  that  contribute  to  the  general  capability.  This 
specific  information  was  to  be  'dentified  with  a  program  element,  which  would  be  a  sub¬ 
division  (or  an  element)  of  a  Major  Force  Program.  The  program  element  is  thus  the 
basic  building  block  for  describing  the  output  of  the  DOD.  Every  mission  of  the  DOD 
must  be  incorporated  into  one  of  the  ten  Major  Force  Programs  and,  in  turn,  into  one  of 
the  many  Program  Elements. 

A  Program  Element  is  defined  as  a  combination  of  personnel,  equipment,  and 
facilities  .  I which J  .  .  constitutes  a  military  capability  or  support  activity.  Thus, 

within  the  Strategic  Forces  Major  Force  Program,  one  would  find  a  Program  Element 
identifying  the  B-l  capability  and  another  Program  Element  identifying  the  PEACE¬ 
KEEPER  missile  capability. [I] 

It  is  obvious  that  these  Program  Elements  provide  a  very  specific  description  of 
the  outputs  of  the  Department  of  Defense.  When  the  SR-71  program  element  is  men¬ 
tioned,  for  example,  an  image  immediately  forms  of  the  high  altitude  reconnaissance  air¬ 
craft  and  its  capabilities.  The  subdivision  into  program  elements  provides  flexibility  for 
the  DOD  decision  maker,  in  that  program  element  may  be  aggregated  in  a  wide  variety 
of  ways,  depending  upon  the  needs  of  the  decision  maker.  The  decision-maker  need  not 
rely  solely  on  the  Major  Force  Program  grouping  if  a  rearrangement  of  Program 

INote  that  there  is  one  Program  Element  fur  th<’  entire  capability  and  not  a  separate  Program  Element  for  each 
B-I  or  PEACEKEEPER  squadron. 
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Elements  is  more  appropriate  for  the  alternatives  being  studied.  Additionally,  trade-offs 
can  be  analyzed  comparing  various  mixes  of  forces  within  any  Major  Force  Program. 

Inputs 

DOD  Directive  7000.1  requires  that  the  Five  Year  Defense  Program  contain  a 
language  such  that  .  .  .  budgeting  .  .  .  will  be  consistent  with  it.  Budgeting  is  a  process 
to  identify  and  obtain  spending  authority  from  Congress;  thus,  it  focuses  on  what  will  be 
purchased  with  the  spending  authority  (i.e.,  the  inputs  to  the  DOD  production  process). 
Since  the  FYDP  needed  to  accommodate  budgeting,  its  structure  had  to  include  input 
information. 

Appropriations.  Appropriations  are  permission  to  obligate  the  Treasury  to  pay 
money  for  goods  or  services.  Appropriations  are  laws  passed  by  Congress  which  author¬ 
ize  the  obligation  and  expenditure  of  certain  dollar  amounts  and  which  specify  the  pur¬ 
poses  for  which  the  funds  may  be  used.  In  1950,  the  numbt:  of  appropriations  was 
reduced  from  2000  to  375,  with  each  appropriation  covering  a  broader  range  of  items  to 
be  purchased.  The  Department  of  Defense  annually  receives  approximately  85  appropria¬ 
tions  which  fall  into  the  five  general  areas. 

Military  Personnel 
Operations  and  Maintenance 
Procurement 
Military  Construction 

Research,  Development,  Test,  and  Evaluation 

Each  of  these  general  areas  represents  several  appropriations.  For  example,  in  the 
area  of  Operations  and  Maintenance,  the  Air  Force  alone  receives  three  appropriations, 
one  for  day-to-day  operations  of  the  active  duty  establishment,  one  for  operation  of  the 
Air  National  Guard,  and  one  for  operation  of  the  Air  Force  Reserve.  Altogether,  there 
are  12-15  annual  appropriations  for  operations  and  maintenance  of  DOD  activities. 
Much  as  the  Major  Force  Programs  broadly  describe  outputs,  the  appropriation 
categories  provide  a  very  general  description  of  inputs.  These  general  descriptions,  how¬ 
ever,  provide  categories  useful  for  Congressional  review  and  decisions. 

Processors 

The  conversion  from  inputs  to  outputs  takes  place  in  the  organization  responsible 
for  the  conversion.  Since  this  organization  is  closest  to  the  production  process,  its 
managers  are  responsible  for  identifying  what  inputs  are  required  to  produce  the  outputs. 
Additionally,  they  are  responsible  for  the  performance  of  their  organization  in  producing 
outputs  effectively  and  efficiently. 

Military  Department  or  DOD  Agency.  The  Military  Department  or  DOD  Agency 
identifies  which  DOD  organizational  element  will  carry  out  the  conversion  process.  With 
the  FYDP  data  base  maintained  at  DOD  level,  the  organizational  identification  goes  no 
lower  than  department  or  agency  level. 

Responsibility  Center.  A  responsibility  center  is  an  organization  headed  by  a 
manager  who  is  assigned  financial  management  responsibility  and  accountability  and 
who,  in  most  instances,  exercises  a  significant  degree  of  control  over  resource  acquisition 
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and  consumption.  Each  Military  Department  or  DOD  Agency  can  be  considered  a 
responsibility  center.  Additionally,  subordinates  such  as  Major  Commands,  Wings,  and 
Squadrons,  will  often  also  be  responsibility  centers.  These  subordinate  units  are  not 
specifically  identified  in  the  Five  Year  Defense  Program,  but  they  may  be  identified  in 
similar  program  data  bases  maintained  by  the  department  or  agency. 


FYDP  Summary 

The  Five  Year  Defense  Program  identifies  each  piece  of  data  using  three  separate 
classification  schemes.  The  data  are  classified  by  input  (appropriation),  by  processor 
(Military  Department  or  DOD  Agency),  and  by  output  (Major  Force  Program).  The 
result  is  a  matrix,  so  that  the  data  can  be  accumulated  along  whichever  lines  are  most 
useful  to  the  decision  maker. 

Data 

Because  the  Five  Year  Defense  Program  is  a  computerized  data  base,  it  is  capable 
of  retaining  massive  amounts  of  data.  This  section  explains  the  nature  of  the  data  which 
are  captured  in  the  Five  Year  Defense  Program,  including  the  types  of  data  maintained, 
the  time  frames  for  which  the  data  are  maintained,  and  the  quantity  of  data  maintained. 
The  FYDP  consists  of  data  relating  to  program  forces,  personnel,  and  costs. 

Program  Forces.  Force  information  identifies  specific  weapon  systems  by  type 
and  model  and  specific  force  organizations  such  as  brigades  and  wings.  As  previously 
identified,  the  FYDP  had  to  be  useful  to  planners.  Since  planners  deal  primarily  in 
terms  of  capabilities,  it  was  necessary  to  include  information  on  approved  force  levels. 
While  the  number  of  organizations  and  types  of  weapon  systems  are  identified,  the 
FYDP  does  not  identify  exact  numbers  of  weapons  systems.  Quantities  are,  however, 
identified  for  new  acquisitions.  Thus,  the  FYDP  may  identify  eight  squadrons  of  B-ls 
programmed  for  FY  8X,  but  it  will  not  identify  the  exact  number  of  B-ls  to  be  opera¬ 
tional.  It  may,  however,  identify  that  seven  B-ls  are  programmed  to  be  acquired  in  Fis¬ 
cal  Year  8X. 

Personnel.  Personnel  information  identifies  manpower  requirements  for  active, 
guard  and  reserve  personnel,  cadets,  and  civilian  employees.  It  is  necessary  to  translate 
forces  into  input  categories  before  identifying  costs.  Because  governmental  employment 
is  of  concern  to  national  policy  makers,  this  resource  is  the  subject  of  extensive  reporting 
requirements  and  controls.  As  a  result,  the  personnel  input  is  specifically  identified  in 
the  FYDP  data. 

Costs.  Cost  information  identifies  the  spending  authority  associated  with  DOD 
programs.  The  cost  data  are  necessary  for  the  budget  and  analysis  processes  and,  thus, 
are  included  in  the  comprehensive  FYDP  data  base. 

Time  Frames 

The  Five  Year  Defense  Program  might  be  expected  to  be  a  data  base  which  covers 
five  years  into  the  future.  This  expectation  is  satisfied,  but  the  FYDP  contains  much 
more  data  than  just  the  five  year  projections. 

Historical  Data.  The  FYDP  serves  as  a  data  base  for  DOD  financial  information 
retaining  all  data  on  DOD  programs  since  the  establishment  of  the  FYDP  in  1961.  The 


data  can  be  used  to  analyze  trends  to  assist  with  projecting  future  requirements.  One 
major  problem  in  developing  such  analyses  is  related  to  the  fact  that  the  FYDP  structure 
has  not  been  static.  The  FYDP  began  with  nine  major  force  programs,  expanded  to 
eleven,  and  now  has  been  reduced  to  the  ten  programs  mentioned  earlier.  As  program 
definitions  have  changed,  the  alignments  of  program  elements  has  changed.  Addition¬ 
ally,  new  program  elements  are  constantly  being  added  as  new  capabilities  are  designed. 
Each  of  these  factors  hampers  the  ability  to  make  valid  comparisons  using  different  years 
of  historical  data. 

Projected  Costs  and  Personnel.  For  development  of  resource  projections,  the 
FYDP  is  truly  a  five-year  program  because  it  retains  cost  and  personnel  projections  for 
five  years  into  the  future.  This  data  is  termed  priced  data  since  it  identifies  quantities  of 
input  (i.e.,  prices)  necessary  to  produce  output. 

Projected  Forces.  Since  planners  necessarily  work  on  a  relatively  long  horizon, 
the  FYDP  retains  force  projections  for  eight  years  into  the  future.  This  longer  time 
frame  is  necessary  to  accommodate  the  long  lead  times  often  required  for  developing  and 
acquiring  new  systems. 

Quantity  of  Data 

From  the  previous  discussion,  it  is  relatively  easy  to  see  why  the  Five  Year 
Defense  Program  is  a  computerized  data  base.  In  January  1984  there  were  approximately 
85  appropriations,  25  DOD  components,  and  2600  program  elements  (including  histori¬ 
cal).  Since  data  covered  the  years  1961  through  1985,  and  included  forces,  personnel,  and 
costs,  the  data  base  theoretically  contained  nearly  a  billion  cells  of  information!  In  fact, 
the  information  retained  is  not  quite  that  voluminous,  because  not  every  program  ele¬ 
ment  is  associated  with  every  DOD  component,  and  because  more  than  800  program  ele¬ 
ments  are  no  longer  active.  They  are  retained,  for  historical  purposes  only,  with  data  no 
longer  added  (for  example,  the  program  element  for  B-47  squadrons).  Almost  half  of  the 
historical  program  elements  are  associated  with  research  and  development  programs 
which  are  either  no  longer  active  (e.g.,  the  XB-70  program  element)  or  which  have  pro¬ 
gressed  beyond  the  research  and  development  stage  into  operational  programs  (e.g.,  the 
F-15  program  element  in  the  research  and  development  program  is  now  historical,  while 
the  F-15  program  element  in  the  general  purpose  forces  program  is  active). 

General  Uses 

Because  the  Five  Year  Defeu-c  Program  is  the  comprehensive  data  base  for  the 
Department  of  Defense,  it  is  used  to  satisfy  both  internal  and  external  information 
requirements.  Some  of  these  uses  are  identified  in  DOD  Handbook  7045.7-H,  FYDP  Pro¬ 
gram  Structure : 

—  Secretary  of  Defense  Posture  Statement 
—  Defense  Manpower  Requirements  Report 
-  Defense  Planning  and  Programming  Category  Reports 
—  Outyear  outlay  estimating 
—  Current/constant  dollar  conversions 
--  Mission-Oriented  Resource  Display 

--  DOD  input  to  Defense  Resource  Model  used  for  Congressional 
Budget  Office  analyses 
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Service  Versions 

Each  service  maintains  its  own  version  of  the  programs  within  the  FYDP  which 
are  managed  by  that  service.  Service  organizational  identifiers  usually  are  carried  to  the 
Major  Command  level  and  expenditures  are  identified  to  detailed  elements  for  expense. 
Service  data  bases  similar  to  the  FYDP  are  the  USAF  Force  and  Financial  Plan,  the 
Army  Five  Year  Defense  Program,  and  the  Department  of  the  Navy  Five  Year  Program 
(DNFYP).  Marine  Corps  requirements  are  identified  in  the  DNF 1  P. 

Development  Criteria 

The  FYDP  structure  was  designed  to  satisfy  several  criteria,  and  it  has  been  suc¬ 
cessful  in  doing  so.  The  structure  was  designed  as  an  operating  tool  of  DOD  managers. 
The  Program  Element  structure  has  enabled  both  the  broad  aggregations  by  Major  Force 
Program  and  the  detailed  analyses  by  Program  Element.  In  this  way  it  is  possible  to 
develop  presentations  which  are  meaningful  to  different  managers.  Because  programs  cut 
across  organizational  lines,  it  is  possible  to  review  the  operation  of  the  entire  DOD  along 
mission  (or  output)  lines  instead  of  reviewing  service-by-service.  The  structure  also  pro¬ 
vides  the  framework  for  DOD  resource  management  because  it  identifies:  (1)  input 
resources,  (2)  who  is  using  them,  and  (3)  what  is  produced  with  those  resources.  This  is 
the  type  of  information  necessary  for  any  performance  measurement  system  and  the 
FYDP  structure  provides  the  framework  for  DOD  accounting  systems. 

Summary 

The  Five  Year  Defense  Program  is  the  comprehensive  data  base  for  the  Depart¬ 
ment  of  Defense.  It  includes  data  on  inputs  (appropriations/elements  of  expense),  proces¬ 
sors  (organizations/responsibiiity  centers),  and  outputs  (major  programs/program  ele¬ 
ments).  Data  including  forces,  personnel,  and  costs  is  retained  since  1961,  with  projec¬ 
tions  of  personnel  and  costs  for  five  years  into  the  future,  and  force  projections  for  eight 
years  into  the  future. 
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THESE  HERE  THE  GENERATIONS  Of  BUBGETING 
BUDGET I NS  BEGAT  LINE  ITERS 
LINE  ITERS  BEGAT  PERFORRANCE  BBNETING 
PERFORRANCE  BONCE TINS  BEGAT  PROGRAIt  BBD6ETING 
PROSAAR  BUDGETING  BEGAT  PLANN l NG-PR06R ARR1 NG-BUDGE T I NG 
PLANNING-PROGRARRING-RUDGETING  BEGAT  HANAGEHENT-NY-OOJCCTtVES 
RANAGERERT-1T -OBJECTIVES  BEGAT  ZERO-BASE  BQBGETIRC 
ZERO-BASE  BUDGETING  BEGAT  EVALBATIBB 
EVALUATION  BEGAT  EXPERIRENTATION 
EXPERIRENTATION  SHOHEB  THAT  NOTHING  WORKS 

ALLEN  SCHICK 


NO  MONEY  SHALL  BE  DRAWN  FROM 
THE  TREASURY.  BUT  IN  CONSEQUENCE 
OF  APPROPRIATIONS  BY  LAW. 


U.S.  BUDGET  OUTLAYS  BY  SUPERFUNCTION 
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PROGRAM  ELEMENT 


•  IDENTIFIABLE  MILITARY  CAPABILITY  OR  SUPPORT 
ACTIVITY  OR  RESEARCH  CAPABILITY 

•  COMBINATION  OF  PERSONNEL.  EQUIPMENT  AND 
INSTALLATIONS 

•  ALL  PROGRAMS  TOGETHER  CONSTITUTE  THE 
COMPLETE  DEFENSE  ESTABLISHMENT 

•  PURPOSE  IS  TO  AGGREGATE  THESE  UNITS 
CONVENIENTLY  FOR  TOP-LEVEL  DECISION  MAKING 


THE  FIVE  YEAR  DEFENSE  PROGRAM 

•  FOUNDATION  OF  DOD  PROGRAMMING  SYSTEM 

•  OFFICIAL  APPROVED  PROGRAMS  FOR  ALL  DOO 
COMPONENTS 

•  BASE  FOR  SUBMISSION  OF  PROPOSED  PROGRAM 
CHANGES 

IT  INCLUDES  . . . 

•  FORCES,  (equipment,  facilities)  FOR  EIGHT  YEARS 
AHEAO 

•  REMAINDER  OF  PROGRAM  (personnel,  costs]  FOR  FIVE 
YEARS  AHEAO 

•  HISTORICAL  DATA  SINCE  1962 
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10-  Support  of  Other  Nations 
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APPROPRIATE  STATUS 

(FG3  APPROPRI  AT  I!)'l  ACCOUNTS  lit  THE  FY  1  APPROPR  l  AT  UN  ACT) 


1974  CONGRESSIONAL  BUDGET  AND 
IMPOUNDMENT  CONTROL  ACT 

©  NEW  ORGANIZATIONS  CREATED 
c  BUDGET  COMMITTEES 
®  ONE  IN  EACH  HOUSE 
O  LINKS  REVENUE/SPENOING  COMMITTEES 
°  CONGRESSIONAL  BUDGET  OFFICE 

•  PROFESSIONAL  STAFF 
©  ECONOMIC  ANALYSES 

•  SPENDING  • SCOREKEEPER" 

©  NEW  SUBMISSIONS 

•  FIVE  YEAR  APPROPRIATIONS  PROJECTIONS 
©  MISSION  BUDGETING 

•  CONTROLS  ON  IMPOUNDMENT 

•  ANNUAL  MILESTONES 

V _ _ _ _ 


PLANNING  . . . 

•  SELECTION  OF  COURSES  OF  ACTION  THROUGH  A 
SYSTEMATIC  CONSIDERATION  OF  ALTERNATIVES 

PROGRAMMING  . . . 

•  MORE  SPECIFIC  DETERMINATION  OF  PERSONNEL 
MATERIEL.  ANO  FACILITIES  NECESSARY  TO 
ACCOMPLISH  OBJECTIVES 

BUDGETING  . . . 

•  PRICING  OUT  APPROVED  PROGRAMS 

•  OBTAINING  FUNDS  TO  IMPLEMENT  APPROVED 
PROGRAMS 
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LESSON  TITLE:  Solicitation  Process 
TIME:  1  hr 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  purpose  of  the  solicitation  process,  the  major  documents  and 
participants  involved  in  the  process  and  their  functions  in  the  systems 
acquisition  process,  and  the  appropriateness  of  different  types  of 
contracts  in  various  situations. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  State  the  purpose  of  the  solicitation  process. 

b.  Describe  the  purpose  of  the  following  in  the  solicitation  and  acquisition 
process: 

(1)  Acquisition  Plan 

(2)  Program  Management  Plan  (PMP) 

(3)  Work  Breakdown  Structure  (WBS) 

(4)  Statement  Of  Work  (SOW) 

(5)  Contract  Data  Requirements  List  (C'DRL) 

(6)  Specifications  and  Standards 

(7)  Source  Selection  Plan  ( SSP ) 

(8)  Request  For  Proposal  ( RFP ). 

c.  Describe  the  roles  of  the  following  in  the  source  selection  process: 

(1)  Source  Selection  Authority  (55.4) 

(2)  Source  Selection  Advisory  Council  (55.4  C) 

(3)  Source  Selection  Evaluation  Board  (SSEB). 

d.  Describe  the  basic  differences  between  fixed-price  and 
cost-reimbursement  type  contracts. 

TOPIC  INTRODUCTION: 

Now  that  you  have  a  basic  understanding  of  what  an  acquisition  program  is,  who 
the  important  players  are  in  meeting  your  program  goals  and  objectives,  and  how  the 
budget  process  is  structured  to  support  the  financial  management  of  funds,  we  need  to 
get  this  all  in  writing  with  a  contractor,  to  make  something  happen.  The  government 
has  formalized  procedures  and  policy  on  how  to  award  a  contract,  as  described  in  the 
Federal  Acquisition  Regulations  (FAR),  and  implemented  by  each  federal  department. 
Of  course,  the  Department  of  Defense  supplements  the  FAR  with  regulations,  called  the 
DFAR,  and  the  Air  Force  also  supplements  the  FAR  and  DFAR  to  meet  its  particular 
requirements.  This  block  introduces  the  basic  building  blocks  in  the  solicitation  process; 
the  process  of  soliciting  industry  for  proposals  in  meeting  mission  needs,  program  goals 
and  objectives.  There  arc  important  steps,  in  the  solicitation  process,  that  must  be 
addressed  and  documented  before  we  can  solicit  industry  and  award  a  contract.  As  pro¬ 
gram  manager,  you  will  probably  be  involved  in  this  process,  either  in  generating  these 
documents,  reviewing  these  documents,  or  supporting  other  solicitations. 


METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  The  Solicitation  Process ,  by  Capt  Adler,  AFIT/LSY 

b.  AFSCR  550-23,  Streamlined  Source  Selection 

c.  Solicitation  videotape 

d.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  \  idco  monitor  and  3/4"  tape  plaver 
REFERENCES: 

a.  Public  Law  98-3(39,  Competition  in  Contracting  Act  ( CICA ) 

b.  DOD  Directive  4105.62.  Selection  of  Contractual  Sources  for 
Major  Defense  Systems 

c.  AFR  70-15  (22  Feb  84),  Source  Selection  Policy  and  Procedures 

d.  AFSCR  80-15  (31  Dec  74),  R&D  Source  Selection 

e.  ASDP  800-7,  Source  Selection  Guide 

f.  Federal  Acquisition  Regulation  (FAR),  Parts  15,  16  &  17,  1984 

g.  DOD  FAR  Supplement ,  Parts  16  and  17,  1984 

h.  Manual  for  Contract  Pricing  (ASP M  #1),  1986 

i.  AFSCR  550-2S,  Streamlined  Source  Selection 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  The  Solicitation  Process 

b.  Read  AFSCR  550-23,  Streamlined  Source  Selection 

c.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  Describe  how  the  Work  Breakdown  Structure  can  support  program  office  tasks 
and  contractor  cost  and  schedule  performance  measurement. 


2.  You  are  the  Program  Manager  for  a  major  program  entering  into  the  Full-Scale 
Development  phase.  You  are  preparing  for  an  upcoming  competitive  source  selection  so 
preparations  are  being  made  in  support  of  this  effort.  What  solicitation  events  and 
actions  should  be  happening  or  should  you  be  considering  in  support  of  the  source  selec¬ 
tion? 
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3.  Briefly  describe  what  elements  need  to  be  considered  in  developing  the  RFP . 
Assume  you  have  a  non-major  program  that  is  transitioning  into  the  Concept 
Demonstration/Validation  phase. 

4.  Briefly  describe  the  differences  and  commonalities  in  the  Acquisition  Plan,  Pro¬ 
gram  Management  Plan,  and  other  lower  level  program  office  plans. 

[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 
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CDRL 

CPPF 

CPIF 

DSSP 

FAR 

FFP 

FPI 

IFB 

ILSP 

PCO 

PMP 

PR 

SOW 

SSA 

SSAC 

SSEB 

SSP 

WBS 


Contract  Data  Requirements  List 
Cost-Plus -Fixed-Fee 
Cost-Plus-Incentive-Fee 

Defense  Standardization  &  Specification  Program 

Federal  Acquisition  Regulation 

Firm  Fixed-Price 

Fixed-Price  Incentive 

Invitations  for  Bids 

Integrated  Logistics  Support  Plan 

Procuring  Contracting  Officer 

Program  Management  Plan 

Purchase  Request 

Statement  of  Work 

Source  Selection  Authority 

Source  Selection  Advisory  Council 

Source  Selection  Evaluation  Board 

Source  Selection  Plan 

Work  Breakdown  Structure 


a. 
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THE  SOLICITATION  PROCESS 
INTRODUCTION 

The  solicitation  process  is  used  by  the  Government  to  determine  which 
contractor(s)  are  offering  the  best  overall  system  in  response  to  a  government  require¬ 
ment.  One  of  the  prime  reasons  for  having  such  a  procedure  is  to  insure  that  the  govern¬ 
ment  benefits  from  competition  when  only  a  few  suppliers  are  capable  of  building  a 
sophisticated  weapon  system.  The  source  selection  process  is  initiated,  pending  solicita¬ 
tion  by  the  government,  for  acquiring  services  or  product(s). 

METHODS  OF  SOLICITATION 

Invitation  For  Bids 

The  method  of  solicitation  generally  takes  one  of  two  major  forms.  If  sealed  bids 
are  used,  formerly  called  Formal  Advertising ,  the  solicitation  instrument  is  called  the 
Invitation  For  Bids  ( IFB ).  This  method  is  quite  rigid  and  inflexible  in  its  implementa¬ 
tion.  It  has  its  origin  in  a  congressional  enactment  of  1809  which  stipulated  that  formal 
advertising  would  be  required  in  the  procurement  of  all  supplies  and  services  required  by 
the  Government  when  the  situation  is  practicable  and  feasible.  The  original  purpose  was 
to  preclude  granting  special  consideration  to  any  individual  or  groups  of  individuals  and 
to  afford  the  Government  the  benefits  of  open  competition.  In  the  years  to  follow,  there 
have  been  departures  from  this  stringent  method  of  procurement,  particularly  during 
periods  of  war,  national  emergencies  or  occasions  wherein  resort  to  formal  advertising 
was  inappropriate.  In  this  respect,  the  FAR  defines  the  situation  as  being  practicable  and 
feasible  if  it  meets  all  of  the  following  prerequisites: 

(1)  Specifications.  To  assure  free  and  full  competition  there  must  be  detailed 
specifications  so  that  all  potential  bidders  understand  the  requirement  of  the 
particular  transaction.  The  specifications  must  be  free  of  ambiguities,  firm  and 
not  susceptible  to  unnecessary  and  frequent  change. 

(2)  Adequate  Competition.  There  must  be  a  sufficient  number  of  suppliers 
who  indicate  an  interest  in  obtaining  the  contract. 

(3)  Adequate  Time.  There  must  be  ample  lead  time  from  receipt  of  the  pro¬ 
gram  directive  to  the  delivery  date  of  the  supplies  or^ervices. 

(4)  Adequate  Price  Criteria.  Price  and  price  related  criteria  must  be  adequate 
contract  award  criteria.  If  technical  discussion  is  required,  the  sealed  bid 
method  cannot  be  used.  Also,  an  IFB  must  result  in  a  Firm  Fixed  Price  type 
contract  only.  (In  periods  of  high  inflation  a  Fixed  Price  with  Escalation  type 
contract  may  also  be  used.) 

Request  For  Proposal 

However,  the  acquisition  of  defense  systems  (managed  in  the  Air  Force  by  Air  Force 
Systems  Command)  generally  does  not  satisfy  these  prerequisites  and,  therefore,  uses  the 
competitive  proposals  or  negotiation  method  of  procurement  in  which  the  Request  For 
Proposal  ( RFP )  is  the  solicitation  instrument.  This  course  will  concentrate  on  the  RFP 
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as  the  solicitation  instrument.  While  the  RFP’s  content  is  substantially  the  same  as  an 
IFB’s,  it  does  differ  in  certain  notable  respects.  For  instance,  the  RFP  should  preferably 
be  written,  but,  in  certain  situations,  (e.g.,  an  emergency  or  other  unusual  circumstance) 
it  may  be  in  telephonic  or  telegraphic  form.  While  specifications  and/or  drawings  are 
preferable,  they  are  not  mandatory  as  is  the  case  in  sealed  bidding.  However,  under  nor¬ 
mal  conditions,  where  the  negotiation  method  is  utilized,  the  contracting  officer,  in 
preparing  the  RFP,  must  conform  to  all  the  requirements  prescribed  in  the  IFB  (i.e.,  ade¬ 
quate  distribution  to  qualified  offerors  and  circulation  of  the  RFP  well  in  advance  of  the 
time  set  for  the  closing  of  the  offer  period). 

ACQUISITION  PLAN 

Planning  for  release  of  an  RFP  to  industry  requires  the  government  to  complete 
several  key  documents  before  asking  for  contractor  proposals.  Federal  policy,  established 
in  the  Federal  Acquisition  Regulation  (FAR),  requires  acquisition  planning  to  begin  as 
soon  as  an  agency  need  is  identified;  preferably  well  in  advance  of  the  fiscal  year  in  which 
contract  award  is  necessary.  This  acquisition  planning  is  consistent  with  the  overall  stra¬ 
tegy  for  managing  the  acquisition  and  is  usually  documented  in  an  acquisition  plan  soon 
after  program  direction  is  received  and  funding  is  approved.  The  acquisition  plan  serves 
a  threefold  purpose: 

(1)  To  ensure  the  government  meets  its  needs  in  the  most  effective,  economical, 
and  timely  manner. 

(2)  To  reduce  acquisition  risk  by  causing  the  acquisition  planner  to  think 
through  the  acquisition  process  before  the  fact  so  that  he  is  aware  of  the  steps 
to  be  taken,  activities  to  be  integrated,  problems  to  be  resolved,  and  risks  to  be 

\  expected. 

(3)  To  execute  an  effective  integration  of  the  various  functional  plans  such  as 
the  System  Engineering  Master  Plan,  Integrated  Logistic  Support  Plan,  Test 
and  Evaluation  Master  Plan,  etc.  (See  Figure  6-1). 

t  The  acquisition  plan  serves  as  a  living  document,  in  that  it  matures  or  evolves 

over  time,  as  more  current  information  becomes  available  and  relevant.  Because  of 
the  evolutionary  nature  of  the  process,  the  FAR  requires  that  the  acquisition  plan  be 
reviewed  and  revised  throughout  the  acquisition  cycle. 

PROGRAM  MANAGEMENT  PLAN 

A  similar  document  that  needs  to  be  reviewed  and  revised  is  the  Program 
Management  Plan  ( PMP ).  The  purpose  of  the  PMP  is  to  unify  the  efforts  planned 
and  assist  the  program  office,  supporting  command,  and  operating  command  person- 
.  nel  in  working  toward  a  common  goal.  As  the  thrust  of  the  acquisition  plan  is  to 

properly  plan  for  subsequent  government  contracts  with  industry,  the  thrust  of  this 
plan  stems  from  the  acquisition  strategy  and  encompasses  all  other  aspects  of  the 
program.  Thus,  quite  commonly,  we  will  see  acquisition  plans  written  on  an  indivi- 
i  dual  contract  basis  but  certainly  revised  prior  to  each  new  phase  of  acquisition.  The 

*.  Procuring  Contracting  Officer  (PCO)  usually  writes  and  maintains  the  Acquisition 

Plan.  The  program  manager,  however,  has  overall  responsibility  for  the  PMP.  The 
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ACQUISITION  PLANNING  RELATIONSHIPS 
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FIGURE  6-1 


program  manager  must  compile  the  PMP  from  inputs  provided  by  program  partici¬ 
pants,  including  supporting  and  operating  command  personnel,  and  appropriate 
staff  and  functional  areas.  The  PMP  must  provide  the  minimum  essential  informa¬ 
tion  needed  to  outline  the  overall  strategy  for  the  program.  Subordinate  plans,  such 
as  the  technical  order  master  plan,  maintenance  plan,  acquisition  plan,  support 
equipment  acquisition  plan,  configuration  management  plan,  and  integrated  com¬ 
munications  support  plan  will  develop  details  in  the  various  functional  and  support 
areas.  Program  managers  must  coordinate  the  original  (basic)  PMP  and,  major  revi¬ 
sions  of,  or  additions  to,  the  basic  PMP  over  time.  Coordination  should  be  limited 
to  only  those  offices  directly  affected  by  the  plan.  The  basic  PMP  must  be  issued  by 
the  date  specified  in  the  Program  Management  Directive  (PMP).  It  may  be  incre¬ 
mentally  updated,  depending  on  requirements  and  availability  of  information.  An 
update  must  be  made  whenever  a  significant  program  change  occurs,  or  at  least 
yearly.  Figure  6-2  contains  a  list  of  sections,  by  subject,  for  a  typical  PMP.  Sec¬ 
tions  may  be  added  or  deleted  as  required.  Each  section  must  be  concise  and  con¬ 
tain  only  essential  details,  usually  in  summarized  form.  Normally,  planning  or 
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implementing  documents  (like  the  acquisition  plan)  that  contain  details  of  func¬ 
tional  activities  need  only  be  referenced  in  the  appropriate  section  of  the  PMP. 

SECTION  SUBJECT 

1  Program  Summary  and  Authorizations 

2  Intelligence 

3  Program  Management 

4  System  Engineering  and  Configuration  Mgt 

5  Test  and  Evaluation 

6  Information  Systems 

7  Operations 

8  Civil  Engineering 

9  Logistics 

10  Manpower  and  Organization 

11  Personnel  Training 

12  Security 

13  Directives.  Specifications,  and  Standards 

Figure  6-2 

WORK  BREAKDOWN  STRUCTURE 

The  common  thread  that  ties  all  plans  and  documents  together  is  the  Work 
Breakdown  Structure  (WBS).  This  is  a  product-oriented  family  tree  composed  of 
hardware,  services,  and  data  that  result  from  project  engineering  efforts  during  the 
development  and  production  of  a  defense  material  item  or  weapon  system.  MIL- 
STD-881A  describes  the  WBS  for  use  by  both  contractors  and  DOD  components  in 
the  development  of  work  breakdown  structures  for  defense  material  items.  Figure 
6-3  contains  an  example  of  the  upper  three  levels  of  an  aircraft  system  that  would 
be  found  in  MIL-STD-881A.  Most  contractors  manage  their  work  according  to  a 
format  similar  to  this,  at  whatever  level  is  necessary  to  meet  established  schedules, 
and,  that  has  been  validated  by  the  Defense  Department.  The  Air  Force  will  there¬ 
fore  manage  contractor  efforts  according  to  information  presented  by  the  contractor 
in  WBS  format.  There  are  four  basic  WBS  formats  highlighted  in  MIL-STD-881A, 
all  of  which  could  be  applicable  to  a  weapon  system  program: 

(1)  Summary  WBS  --  this  WBS  is  nothing  more  than  the  upper  three  lev¬ 
els  of  the  defense  material  item,  or  weapon  system,  taken  verbatim  out  of 
MIL-STD-881A. 

(2)  Project  Summary  WBS  —  once  the  Summary  WBS  is  complete,  unique 
program  or  project  needs  are  determined  through  the  systems  engineering 
process,  and  the  Summary  WBS  is  appropriately  tailored  to  best  represent 
the  program. 

(3)  Contract  WBS  -  the  program  office  will  structure  a  Contract  WBS  by 
selecting  those  elements  of  the  Project  Summary  WBS  that  are  applicable 
to  the  contractor,  e.g.,  the  contractor  would  be  responsible  for  the  avionics 
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SUMMARY  WORK  BREAKDOWN  STRUCTURE 
Finure  6-3 

package  of  an  aircraft  but,  possibly,  not  the  spares  or  spare  parts. 

(4)  Project  WBS  —  a  compilation  of  all  elements  of  the  Project  Summary 
WBS  and  Contract  WBS  necessary  for  project  management  and  other 
related  activities.  The  formal  Project  WBS  will  be  completed  prior  to  the 
initiation  of  production. 

The  WBS,  in  its  several  forms,  is  an  extremely  useful  device  as 
project/program  managers  engage  in  planning  and  controlling  their  programs. 
MIL-STD-881A  is  intended  to  be  a  guide.  Rigid  adherence  to  the  formats  is  not 
required.  A  WBS.  however,  if  sufficiently  written,  defines  the  program’s  total  objec¬ 
tives;  it  relates  the  various  work  efforts  (parts)  to  the  overall  product  (whole  sys¬ 
tem).  The  WBS  is  the  foundation  for: 

(1)  Program  and  technical  planning. 

(2)  Statement  of  Work  preparation. 

(3)  Schedule  definition. 

(4)  Cost  estimation  and  budget  formulation. 

(5)  Progress  status  reporting  and  problem  analysis. 

STATEMENT  OF  WORK 

With  the  WBS  defined  and  developed,  it  is  possible  to  prepare  the  Statement 
of  Work  (SOW).  The  SOW  is  a  document  that  defines  efforts  to  be  accomplished 
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ranging  from  small  research  studies  to  the  acquisition  of  a  major  weapon  system.  It 
establishes  non-specification  tasks/requirements  and  identifies  the  work  effort.  The 
SOW  is  a  tasking  document  that  defines  the  scope,  or  outer  limits,  of  the 
contractor’s  effort.  The  SOW  is  part  of  the  RFP  and  the  contract.  There  are  three 
sections  in  the  SOW  format: 

(1)  Section  1  —  (Scope). 

(2)  Section  2  —  (Applicable  Documents). 

(3)  Section  3  --  (Requirements). 

The  SOW  is  a  key  element  of  the  RFP  and  serves  as  a  basis  for  contractor 
response  and,  subsequent  government  evaluation  of  proposals  in  source  selection. 
After  contract  award,  requirements  of  the  work  statement  (and  associated 
specifications)  constitute  the  standard  and  discipline  for  the  contractor’s  effort.  It 
comprises  the  baseline  against  which  progress  and  subsequent  contractual  changes 
are  measured.  Both  parties,  the  government  and  the  contractor,  will  look  to  the 
language  of  the  SOW  as  a  key  document,  defining  responsibilities  of  the  contractor 
and  the  government. 

CONTRACT  DATA  REQUIREMENTS  LIST 

Directly  related  to  the  SOW  is  the  Contract  Data  Requirements  List  ( CDRL ). 

|  The  CDRL  is  a  list  of  data  requirements  that  is  authorized  for  a  specific  procure- 

t  ment  and  is  made  part  of  the  contract.  The  CDRL  is  one  of  the  two  places  in  the 

!  contract  that  can  establish  a  requirement  for  the  contractor  to  deliver  data.  The 

•  other  area  is  by  specific  contract  clauses,  formerly  called  the  general  provisions  sec¬ 

tion  of  the  contract,  which  brings  in  Federal  Acquisition  Regulation  clauses  applica¬ 
ble  to  your  contract.  Both  the  CDRL  and  the  clauses  require  Office  of  Management 
N  and  Budget  control  over  the  data  being  collected,  as  regulated  by  the  Paperwork 

Reduction  Act  (Public  Law  96-511).  CDRL  data  may  best  be  thought  of  as  data 
directly  linked  to  SOW  tasks.  (See  Data  Management  section  for  more  informa¬ 
tion.) 

DEFENSE  STANDARDIZATION  AND  SPECIFICATION  PROGRAM 

Also  important  in  the  solicitation  process,  and  included  in  most  government 
contracts,  are  specifications,  standards,  and  related  documents.  These  are  docu¬ 
ments  that  are  part  of  the  Defense  Standardization  and  Specification  Program 
(DSSP)  that  establish  and  define  requirements  for  purchased  material,  processes, 
procedures,  practices,  methods,  and  data.  Specifications  are  documents  prepared 
specifically  to  support  acquisition  and  cover  items  which  vary  greatly  in  complexity. 
They  establish  essential  requirements  in  terms  of  complete  design  details  or  in  terms 
of  performance,  but  most  instances  in  terms  of  both  design  and  performance. 
Specifications  should  establish  requirements  in  terms  of  performance  in  order  to  per¬ 
mit  solicitations  of  competitive  bids  from  the  largest  segment  of  industry. 

Standards,  on  the  other  hand,  are  documents  that  establish  engineering  and 
technical  requirements  for  processes,  procedures,  practices  and  methods  that  have 
been  adopted  as  standard.  They  are  created  primarily  to  serve  the  needs  of 
v  designers.  Their  purpose  is  to  control  variety,  and  they  include  materials,  items, 

engineering  practices,  processes,  codes,  symbols,  type  designations,  definitions, 
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nomenclature,  test,  inspection,  packaging  and  preservation  methods  and  materials, 
and  other  standardization  topics. 

Other  related  documents  include  drawings  or  handbooks.  A  handbook  is  a 
reference  document  which  brings  together  procedural  and  technical,  or  design,  infor¬ 
mation  related  to  commodities,  processes,  practices,  and  services.  Drawings  are 
referenced  in  many  standardization  documents  and  supply  management  records. 
Conversely,  specifications  and  standards  are  often  referenced  in  drawings  to  identify 
the  materials,  processes  and  standard  items  incorporated  in  assemblies  ami  equip¬ 
ment. 

The  Air  Force  decision  process  (or  what  to  put  in  a  cont  ract)  for  specifications, 
standards,  and  other  related  documents  is  a  three  step  process: 

(1)  the  selection  from  the  total  realm  of  available  documents,  those  docu¬ 
ments  that  have  a  specific  application  to  a  particular  acquisition  program. 

(2)  the  selection  of  the  specific  applicable  requirements  in  these  docu¬ 
ments. 

(3)  an  examination  and  tailoring  of  the  selected  requirements  so  that  each 
document  imposes  the  optimum  set  of  requirements  to  support  the  partic¬ 
ular  system  during  its  acquisition  and  ownership. 

PURCHASE  REQUEST 

Another  important  solicitation  document  is  the  Purchase  Request  {PR).  A  PR 
is  a  funding  document  used  to  initiate  procurement  action.  The  PR  is  a  direct  cite 
document  which  means  that,  before  a  contract  can  be  awarded,  there  has  to  be 
authorized  funding  available  in  order  to  obligate  the  government  for  work  per¬ 
formed.  The  PR  is  usually  initiated  after  the  SOW,  CDRL,  and  specifications  are 
complete.  The  PR  is  important  in  determining  the  dollar  magnitude,  advertising, 
competition,  and  scope  of  the  intended  source  selection  and  contract  award. 

SOURCE  SELECTION  PLAN 

The  Source  Selection  Plan  ( SSP )  usually  provides  a  subsequent  smooth,  efficient 
source  selection  process  in  competitive  solicitations.  The  SSP  establishes  procedures 
for  accomplishing  three  prime  objectives: 

(1)  to  select  the  source  whose  proposal  has  the  highest  degree  of  realism 
and  credibility  and  whose  performance  is  expected  to  best  meet  govern¬ 
ment  objectives  at  an  affordable  cost. 

(2)  to  ensure  impartial,  equitable,  and  comprehensive  evaluation  of  com¬ 
petitors’  proposals  and  related  capabilities. 

(3)  to  maximize  efficiency  and  minimize  complexity  of  solicitation,  evalua¬ 
tion,  and  the  selection  decision. 

Prior  to  the  issuance  of  an  RFP,  a  SSP  shall  be  approved  by  the  Source  Selec¬ 
tion  Authority  (5SA),  the  government  official  in  charge  of  selecting  the  source.  The 
program  manager  is  responsible  for  drafting  the  plan  and  obtaining  its  approval 
from  the  SSA.  The  SSP  should  complement  the  acquisition  plan  and  should  sum¬ 
marize  the  overall  acquisition  strategy  contemplated  for  the  program.  The  SSP 
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should  include  a  discussion  of  the  extent  of  competition  contemplated,  a  description 
of  the  evaluation  techniques  to  be  used,  and  the  schedule  for  significant  actions 
required  between  the  designation  of  the  SSA  and  signing  of  the  definitive  contract. 
Also  included  in  the  SSP  is  a  description  of  the  organizational  structure  to  be  used 
in  the  source  selection  process.  The  organization  is  normally  composed  of  three  lev¬ 
els;  the  SSA,  the  Source  Selection  Advisory  Council  ( S.SAC ),  and  the  Source  Selec¬ 
tion  Evaluation  Board  ( SSEB ).  The  SSAC  is  a  group  of  senior  military  and/or 
government  civilian  personnel  designated  to  serve  as  the  staff  and  advisor  to  the 
SSA  during  the  process.  It  reviews  the  SSEB  findings,  prepares  a  proposal  analysis 
of  each  offer,  and  compares  the  proposals  to  one  another.  The  SSAC  is  the  body 
that  considers  the  contractor’s  past  performance. 

The  SSEB  is  a  group  of  military  and/or  civilian  personnel,  appointed  by  the 
SSAC,  representing  various  functional  and  technical  disciplines.  Their  task  is  to 
evaluate  proposals  against  established  criteria,  not  proposals  versus  proposal,  and  to 
develop  summary  facts  and  findings  during  the  source  selection  process.  The  SSEB 
is  the  heart  of  the  selection  team.  The  manning  would  typically  include  personnel 
from  logistics,  cost  analysis,  operational,  contract,  legal,  and  technical  areas. 

TYPES  OF  CONTRACTS 

The  FAR  usually  requires  that  contracting  officers  prepare  written  solicita¬ 
tions,  (the  RFP)  and  resulting  contracts,  using  the  uniform  contract  format  outlined 
in  FAR  15.406-1.  The  uniform  contract  format,  shown  in  Figure  6-4,  is  designed  to 
facilitate  preparation  of  both  the  solicitation  and  the  resulting  contract.  Sections  A 
through  J  (Parts  I-III)  contain  documents  that,  in  effect,  constitute  a  draft  or  model 
contract.  In  fact,  the  purpose  of  structuring  the  RFP  this  way  is  to  provide  basic 
documentation  that  will  eventually  form  a  major  part  of  the  resultant  contract. 
The  remaining  sections  (Part  IV)  in  the  uniform  contract  format  are  important 
parts  of  the  RFP,  but  are  not  physically  included  in  the  resulting  contract. 

The  result  of  the  solicitation  and  subsequent  source  selection  process  is  a 
mutually  agreed  upon  contract  for  acquisition  of  supplies  and/or  services.  This 
mutually  agreed  upon  contract  will  be  one  of  two  basic  types  of  contract  categories 
in  Air  Force  acquisitions:  cost-reimbursement  contracts  and  fixed-price  contracts. 
With  cost-reimbursement  type  contracts,  the  government  is  required  to  reimburse 
the  contractor  for  all  allowable,  allocable  costs,  reasonably  incurred  in  contract  per- 
forr  'nee,  up  to  the  amount  originally  negotiated  for  contract  performance.  Once 
the  m  vis  run  out.  the  contracting  officer  authorizes  additional  funding,  if  available, 
ana,  n  the  government  decides  to  do  so.  Since  the  original  contract  price  was  predi¬ 
cated  on  an  estimate,  the  contracting  officer  can  provide  additional  funding  without 
receiving  new  consideration  from  the  contractor.  Thus,  the  cost-reimbursement  type 
contract  allows  the  government  considerable  flexibility  (at  additional  cost)  in 
redirecting  the  contractor’s  efforts,  within  the  scope  of  the  contract,  in  response  to 
changes  in  technology  or  mission  requirements. 

The  major  difference  between  fixed-price  and  cost-reimbursement  contracts  is 
that,  with  fixed-price  contracts,  funding  of  cost  overruns  and  cost  growth  beyond  a 
firm  fixed-price  (or  ceiling  price)  is  legally  impossible.  The  contractor  is  obligated  to 
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UNIFORM  CONTRACT  FORMAT 


Section  A 
B 
C 
D 
E 
F 
G 
H 


PART  1  -  THE  SCHEDULE 


Solicitation/Contract  Form 

Supplies  or  Services  and  Prices/Costs 

Descr iption/ Specifications /Work  Statement 

Packaging  and  Marking 

Inspection  and  Acceptance 

Deliveries  or  Performance 

Contract  Administation  Data 

Special  Contract  Requirements 


PART  2  -  CONTRACT  CLAUSES 


I  Contract  Clauses 


PART  3  -  LIST  OF  DOCUMENTS , EXHIBITS , ATTACHMENTS 


J  List  of  Attachments 


PART  4  -  REPRESENTATIONS  AND  INSTRUCTIONS 


K  Representations,  Certifications,  Statements 

L  Instructions,  Conditions,  Notices  to  offerors 

M  Evaluation  Factors  for  Award 


FIGURE  6-4 

deliver  a  specified  end-product  at  the  contractual  price,  regardless  of  the  actual  cost. 
If  the  contractor’s  actual  costs  are  lower  than  the  estimates  used  to  establish  the 
agreed-on  price,  the  contractor  makes  more  profit. 

These  two  categories  of  contracts,  cost-reimbursement  and  fixed-price,  fall 
along  a  risk  spectrum  reflecting  the  varying  cost  risk  borne  by  the  contractor  and 
the  government.  At  one  end  of  the  spectrum  is  the  Firm  Fixed-Price  ( FFP )  con¬ 
tract,  where  the  contractor  bears  the  maximum  cost  risk.  The  FFP  contract  is  most 
appropriate  when  reasonably  definitive  design  or  performance  specifications  are 
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available,  such  as,  for  the  purchase  of  standard  or  modified  commercial  items, 
standardized  military  items,  or  acquisitions  in  the  production  phase.  The 
government’s  ability  to  obtain  an  FFP  contract  is  directly  related  to  the 
contractor’s  ability  to  objectively  estimate  anticipated  costs.  If  the  uncertainties  of 
contract  performance  can  be  identified  and  their  impact  on  costs  reasonably 
estimated,  the  contractor  will  be  willing  to  accept  a  contract  on  an  FFP  basis. 

At  the  other  end  of  the  spectrum  is  the  Cost-Plus-Fixed-Fee  ( CPFF )  contract, 
where  the  fee  is  fixed,  and  the  government  pays  all  of  the  contractor’s  actual  costs, 
which  are  allowable  and  allocable  up  to  a  maximum  price.  The  CPFF  is  most 
appropriate  when  estimates  of  cost,  performance,  and  schedule  involve  large  techni¬ 
cal  uncertainties  and  when  both  the  contractor  and  the  government  desire  to  retain 
as  much  flexibility  and  opportunity  for  change  as  possible,  such  as  in  the  concept 
exploration  or  demonstration/validation  phase.  With  the  CPFF,  the  contractor 
bears  the  minimum  cost  risk.  There  are  numerous  other  types  of  contracts,  like 
Fixed-Price  Incentive  ( FPI)  or  Cost-Plus-Incentive-Fee  ( CPIF ).  that  fall  between  the 
risk  associated  with  the  FFP  and  CPFF,  but  these  are  all  basically  derivatives  of 
the  FFP  and  CPFF  concept,  depending  on  the  risk  associated  with  that  contract. 

SUMMARY 

The  RFP,  then,  is  the  vehicle  the  government  uses  to  ask  industry  for  propo¬ 
sals  for  a  system  using  the  competitive  proposal  procurement  method  and  is  one  of 
the  most  important  documents  in  the  acquisition  cycle.  All  of  the  preparation  and 
planning  for  an  acquisition  goes  into  the  RFP  as  the  key  communication  to  poten¬ 
tial  contractors  on  exactly  what,  how,  and  when  the  government  needs  to  buy. 
When  the  government  issues  an  RFP,  it  is  describing  its  needs  for  particular  goods 
or  services,  and  is  soliciting,  from  industry,  proposals  to  fulfill  those  needs.  Competi¬ 
tors  (or  offerors)  submit  proposals  (cr  offers)  in  response.  Subsequently,  the  govern¬ 
ment  conducts  a  source  selection,  negotiates  with  the  winner,  and  the  contracting 
officer  signs  (accepts)  to  form  a  binding  contract.  Lesson  7  will  cover  this  area  more 
in-depth.  The  RFP  has  particular  significance  in  this  process,  in  that  the  clarity 
and  coherence  with  which  it  is  constructed  can  dramatically  affect  the  events  that 
follow  —  favorably  or  unfavorably.  How  well  the  government  clearly  communicates 
its  needs  in  the  RFP,  for  instance,  will  almost  certainly  influence  the  quality  of  pro¬ 
posals  received,  ease  or  difficulty  of  conducting  source  selection  and  negotiation,  and, 
ultimately,  relative  success  or  failure  of  contract  performance. 
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DEPARTMENT  OF  THE  AIR  FORCE 
Headquarters  Air  Force  Systems  Command 
Andrews  Air  Force  Base  DC  20334-5000 


AFSC  REGULATION  550-23 


28  July  1987 


Commander's  Policies 
STREAMLINED  SOURCE  SELECT  ION 

1  Increasing  leadtimes  threaten  our  ability  to  be  responsive  to  our  users  and  our  drive  to  maintain  acquisition 
excellence  It  is  imperative  that  we  take  every  action  available  to  reduce  the  amount  of  lime  necessary  to  complete 
our  contractual  arrangements.  The  use  of  streamlined  procedures  in  source  selections  has  the  potential  to  signifi¬ 
cantly  reduce  leadtimes  without  jeopardizing  the  time-tested  integrity  of  our  comprehensive  source  selection  process 
Therefore.  I  expect  you  to  incorporate  the  philosophy  outlined  below  to  the  widest  possible  extent  across  our 
acquisitions 

a.  Ensure  y<<u  maintain  challenging  goals  for  all  parties  involved  in  the  source  selection  process  You  should 
strive  to  complete  the  source  selection  process  from  Request  for  Proposal  (RFP)  release  to  source  selection  decision 
in  120  days 

b  Use  draft  RFPs  to  the  maximum  extent  possible  They  are  a  valuable  tool  that  can  pate  requirements  to  the 
bare  essentials  and  reduce  proposal  preparation  and  evaluation  time. 

c  Limit,  whenever  possible,  the  documentation  requirements  The  processing  of  source  selection  documentation 
has  become  loo  lengthy  a  process  and  we  must  constantly  look  for  ways  to  shorten  this  process  Therefore.  I  am 
eliminating  the  requirement  for  contract  strategy  papers  I  expect  you  to  take  similar  action  to  reduce  local  coordina¬ 
tions  and  approvals  to  the  minimum  essential  while  eliminating  duplicative  and  time  wasting  processes,  including 
extensive  ptrlxiefings  and  "dry  runs  ” 

d  Limit  the  size  of  proposals.  The  quality  of  information  contained  in  contractor  proposals  is  far  more  important 
than  the  quantity  Technical  and  management  volumes  should  each  be  limited  to  100  double  spaced  pages  Cost 
proposals  should  also  have  100  pages  as  a  maximum  goat;  although  at  times,  it  may  be  necessary  to  exceed  that 
number  to  meet  the  requirements  of  existing  public  law  Limits  are  also  important  for  responses  to  deficiency  notices 
and  clarification  requests. 

e.  Make  use  of  oral  presentations  ftoui  olferors  to  provide  an  overview  of  each  proposal  after  initial  evaluations. 
This  procedure  can  both  expedite  the  evaluation  and  improve  the  effectiveness  of  the  source  selection  team. 

f.  Encourxg"  the  efectmmr  siibmisst>»n  and  update  of  cost  proposals  It  saves  time,  greatly  reduces  misunder¬ 
standings.  and  will  provide  a  tnajot  impetus  to  the  improvement  of  the  information  available  for  pricing  proposals. 

g  Keep  evaluation  factors  to  the  minimum  necessary  for  selection.  There  are  many  things  we  can  review,  but  it 
is  essential  to  focus  our  limited  resources  on  those  things  we  must  review. 

h.  Establish  small,  expert  evaluation  panels  composed  of  key  people  with  broad  experience  Make  effective  use 
of  the  expert  members  of  the  Source  Selection  Advisory  Council  (SSAC).  They  can  not  only  provide  excellent  and 
timely  advice  but  they  also  can  reaoive  potential  showstopper  issues  within  the  organizations  they  represent. 

i.  Carefully  determine  the  need  for  audit  and  field  pricing  support.  If  an  audit  is  not  required,  it  should  not  be 
requested  When  an  audit  or  field  pricing  support  is  required,  it  should  be  tailored  to  meet  the  needs  of  the  individual 
source  selection. 

j  Assess  each  proposal  realistically  and  carefully  before  inclusion  in  the  competitive  range  With  contractor  bid 
and  proposal  funds  limited  and  our  evaluation  resources  constrained,  we  must  ensure  that  only  proposals  that  have  a 
reasonable  chance  for  selection  are  included  in  the  competitive  range. 

k.  Use  past  performance  as  a  key  determining  factor  of  present  capability  and  give  it  a  high  priority  when 
prescribing  evaluation  factors  in  solicitations.  Careful  consideration  of  past  performance  by  the  SSAC  and  Source 
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Selection  Evaluation  Board  (SSEB)  is  a  critical  contributor  toward  improvement  in  contract  selection  and  perfor¬ 
mance 


2  We  ha\c  established  an  outstanding  process  for  selecting  our  contractors,  one  that  has  proven  its  efficacy  man> 
times  Implementing  this  |«>licy  will  pimitlr  imptovrmrtils  In  Hie  llnirliness  Mint  mrmll  rllii  Irni  >  this  pi<*<  r«  nmt 
will  contribute  significantly  to  our  goal  of  acquisition  excellence.  Keep  in  mind  that  our  purpose  is  to  select  the  best 
contractor  with  a  good  and  demonstrated  track  record.  1  want  you  to  use  every  possible  innovative,  legal,  and 
apptopnate  tool  to  make  this  happen.  Do  not  engage  in  "square  filling"  or  “cover  your  six"  actions.  Do  not 
encourage  "buKhuremanship'"  We  are  here  to  get  what  the  user  needs  and  lo  protect  the  taxpayers'  interests,  not  to 
make  ourselves  look  good  for  checkers  and  inspectors  Comprehensive  and  fair  source  selections  are  critical  items 
for  this  Command,  and  I  expect  your  full  support  and  attention  to  this  important  element  of  acquisition  excellence. 


am  -  A admn  AlB  IX  l«7 
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LESSON  7 


LESSON  TITLE:  Contract  Management 
TIME:  2  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know  the 
role  of  contracting  personnel  in  the  program  office  and  the  environment 
in  which  government  contracting  officers  must  function. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Describe  the  reasons  which  may  disqualify  a  contractor  for  contract 

award. 

b.  List  and  describe  the  responsibilities  of  the  three  types  of  contracting 
officers. 

c.  Define  the  term  contract  and  identify  the  elements  that 
must  be  included. 

d.  Define  the  term  agency  and  describe  how  it  relates  to  Government 
contracting. 

e.  Identify  the  functions  performed  by  the  Contract  Administration  Office. 

TOPIC  INTRODUCTION: 

The  previous  lesson  talked  about  the  solicitation  process  and  some  of  the  important 
document*  which  must  be  addressed  to  support  the  competitive  proposal  method  of  soli¬ 
citation  (the  one  most  frequently  accomplished  in  Department  of  Defense  acquisitions). 
This  lemon  addresses  activities  from  a  different  angle.  The  first  videotape  addresses  the 
overall  environment  of  the  solicitation,  and  the  source  selection  process,  up  to  contract 
award.  Emphasis  here  is  on  the  contractor’s  proposal  which  is  analyzed  by  the  govern¬ 
ment,  to  make  sure  it’s  responsive  and  timely,  is  reasonable,  and  whether  the  contractor 
is  a  responsible  contractor.  In  describing  the  steps  that  lead  to  contract  award,  the  con¬ 
tracting  officer’s  authority  is  also  addressed,  with  regard  to  the  three  types  of  contracting 
officers  and  their  basic  responsibilities.  The  second  videotape  covers  the  organizations 
responsible  for  administering  government  contracts,  and  what  types  of  information  they 
can  supply  you  with,  in  managing  your  program. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  Contracting  Authority,  by  Maj  Sand,  AFIT/LSP 

b.  Contract  Management  videotape 

c.  Lesson  viewgraphs 

AUDIO- VISUAL  AIDS:  Chalkboard 
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INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  Federal  Acquisition  Regulation  (FAR) 

b.  DOD  Far  Supplement  (DOD  FAR  SUPP) 

c.  Defense  Acquisition  Regulation  ( DAR ) 

d.  AFR  110-9,  Procurement  Law 

e.  ASPM  #1,  Manual  for  Contract  Pricing 

f.  AFR  70-1,  Do 's  and  Don’ts  of  Industry  Regulations 

g.  AFR  70-1-5,  DOD/ NASA  Incentive  Contracting  Guide 

h.  AFSCR  70-7,  AFSC  Procurement  Evaluation  Panel 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Contracting  Authority 

b.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  Ima  New,  the  ACO,  had  been  with  the  government  just  over  one  year.  Until 
this  time  he  relied  heavily  upon  the  vast  experience  of  Good-Old  Boy  when  making  deci¬ 
sions  which  affected  the  contractor.  During  the  morning  coffee  break  Ima  overheard 
Good-Old  Boy  bragging  that  he  had  earned  his  pay  already  that  day  by  directing  the 
contractor  to  do  work  not  covered  by  the  contract;  further,  this  contractor  was  so  naive 
that  Good-Old  Boy  was  certain  that  the  contractor  would  not  complain. 

a.  What  alternatives  does  Ima  have? 

b.  Which  alternatives  would  you  pick?  Why? 

c.  What  additional  factors  would  cause  you  to  select  a  different  alternative? 

2.  An  enforceable  contract  requires  valid  consideration.  How  do  we  determine  if  it 
exists?  How  much  is  enough?  Who  decides? 

3.  Discuss  the  factors  which  establish  and  bound  the  ACO’s  authority. 

4.  Discuss  "agency"  as  it  pertains  to  government  contracts. 

5.  Mr.  E.  Z.  Mark,  the  ACO,  plays  golf  with  Mr.  N.  O.  Good,  an  influential  con¬ 
tractor,  every  Saturday  at  the  Swank  Country  Club.  Mr.  Mark  and  Mr.  Good  are  each 
keenly  aware  of  the  government  standards  of  conduct  and  they  do  not  discuss  business 
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while  foiling.  Mr.  Double  Standard,  a  competitor  of  Mr.  Good,  complains  to  you,  the 
supervisor,  that  Good  is  receiving  preferential  treatment  from  Mr.  Mark.  What  will  you 

do?  Why? 


6.  Mr.  I.  N.  Eppt  was  assigned  as  the  ACO  for  contract  F33675-XO-C-6666.  This 
contract  required  delivery  of  2,500  cluster  bomb  dispensers  to  be  used  on  both  manned 
and  unmanned  aircraft.  During  the  pre-production  review,  it  became  apparent  Mr.  Eppt 
had  ignored  the  advice  of  his  production  and  quality  assurance  specialists,  and  successful 
completion  of  the  contract  was  in  serious  jeopardy.  When  confronted  with  this  situa¬ 
tion,  the  CO  Mr.  Omni  Force,  was  tasked  by  the  program  manager  to  take  any  and  all 
actions  required  to  correct  the  situation. 

a.  What  alternative(s)  does  Mr.  Force  have? 

b.  Which  alternative(s)  would  you  select?  Why? 

c.  What  additional  information  would  you  obtain  before  taking  action? 

7.  Mr.  I.  M.  Portant  is  the  Program  Manager  for  Mister  big,  a  multifaceted  state  of 
the  art  weapon  system  initiated  to  negate  the  chemical  warfare  capacity  of  the  most  bel¬ 
ligerent  adversary  of  the  US.  Mr.  Portant  is  convinced  that  successful  program  comple¬ 
tion  depends  upon  his  personal  involvement  as  the  ACO. 

a.  Is  this  action  possible? 

b.  How  could  Mr.  Portant  best  assure  that  contract  administration  is  accomplish 
in  a  satisfactory  manner? 


8.  Mr.  Cal  Q.  Lator,  Chief,  Engineering  Service  at  DCASMA,  Any  City,  was 
overwhelmed  by  his  own  importance.  When  communicating  with  Ms.  Ima  Slugg,  the 
ACO,  Mr.  Lator  would  use  "engineering-ese"  to  enlarge  his  role  in  even  the  most 
insignificant  of  circumstances.  Ms.  Slugg  has  previously  appealed  without  success  to  the 
DCASMA  Commander  to  correct  Mr.  Lator’s  attitude.  You  have  now  replaced  Ms. 
Slugg.  How  would  you  deal  with  Mr.  Lator? 


0.  Mr.  John  T.  Flexible,  recently  the  CO  for  a  major  weapon  system  has  been  reas¬ 
signed  to  DCASMA,  Nowhere  City,  as  an  ACO.  You  are  his  new  supervisor.  What 
topics  would  you  cover,  during  his  inbriefing,  to  ease  his  transition? 


10.  You  are  the  ACO  for  a  rather  large,  complex  contract.  The  postaward  orienta¬ 
tion  conference  is  to  be  held  right  after  this  meeting.  What  would  you  discuss?  Whom 
would  you  invite?  Under  what  conditions  would  you  decide  to  cancel  the  postaward 
orientation  conference? 


11.  Mr.  Wiley  Foxx  was  the  Program  Manager  for  the  Snake-Eye  Radar  System. 
The  contractor  was  experiencing  difficulties  with  production  of  the  system.  Wiley  sent 
Mr.  Harry  Wolf,  his  production  expert,  into  the  plant  to  help  solve  the  problem.  Mr. 
Meeka  S.  Lamb,  the  ACO,  would  not  let  Wolf  see  the  contractor.  Mr.  Lamb  explained 
what  Wolf  should  work  with  his  production  scheduler,  Mr.  Ura  Wrong,  and  Mr.  Wrong 
would  deal  with  the  contractor.  In  this  way,  Mr.  Lamb  expected  to  keep  the  lines  of 
communications  with  the  contractor  clear  and  direct.  Do  you  think  Mr.  Lamb  is  correct? 
If  not,  what  is  the  best  approach? 


[Acronyms  introduced  in  this  lesson,  and  their  descriptions] 


Chapter  7 


Administrative  Contracting  Officer 
Contract  Administration  Organization(s) 

Contracting  Officer 

Defense  Contract  Administrative  Services 

Defense  Contract  Administrative  Services  Management  Area* 

Defense  Contract  Administrative  Services  Plant 

Representative  Office 

Defense  Contract  Administrative  Services  Regions 
Government  Bill  of  Lading 
Plant  Representative  Office 
Termination  Contracting  Officer 


ACO 

CAOs 

CO 

DCAS 

DCASMAs 

DCAS PROS 

DCASRS 

GBL 

PRO 

TCO 
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CONTRACTING  AUTHORITY 


The  purpose  of  this  chapter  is  to  provide  a  frame  of  reference  within  which  one  can 
understand  the  formation  of  a  simple  contract.  The  essential  elements  in  contract  forma¬ 
tion  arc  analyzed  and  related  to  tin*  intentions  of  the  parties  who  seek  to  enter  the  con¬ 
tractual  relationship.  This  chapter  also  dclines  the  Contracting  Officer  position.  Respon¬ 
sibilities  of  contracting  ollicers  are  divided  and  time-phased;  the  contract  is  awarded  by 
the  Procuring  Contracting  Olficcr  (TCO)’,  il  is  then  assigned  to  an  Administrative  Con¬ 
tracting  Office  (A CO)  for  administration.  In  tiie  event  of  a  termination,  it  is  assigned  to 
a  Termination  Contracting  Officer  ( J'CO)  to  terminate.  This  chapter  focuses  on  the 
authority  of  those  positions. 

1.  The  Contracting  Officer  (CO). 

A  Contracting  Officer  (CO)  is  any  oiiicer  or  civilian  designated  by  the  Air  Force 
with  authority  to  enter  into  and  administer  contracts  for  the  Air  Force.  The  CO  is  the 
only  one  vested  with  authority  to  bind  the  government  contractually  by  entering  into  a 
contract  or  changing  contract  requirements.  Each  CO  is  warranted  by  the  respective 
command,  and  the  authorities  delegated  to  him  are  generally  not  redelegable  (to  someone 
else).  The  Air  Force  has  three  types  of  contracting  officers. 

2.  Authority  of  the  PCO. 

The  contracting  officer  at  the  purchasing  office  which  awards  and  executes  a  con¬ 
tract  for  supplies  or  services  on  behalf  of  tin*  government,  and,  in  the  name  of  the  United 
States  of  America,  by  sealed  bids,  by  competitive  proposals,  or  by  coordinated  or  inter¬ 
departmental  procurement,  and,  when  authorized  by  FAR,  administers  such  contracts. 

3.  Authority  of  the  AGO. 

The  ACO  is  a  duly  appointed  official  who  is  assigned  the  responsibility  for 
administration  of  government  contracts.  As  a  representative  of  the  Government,  the 
ACO  may  administer  any  Government  contract,  including  all  amendments.  The  scope  of 
this  authority  is  limited  by  the  appointing  official.  The  authority  of  the  ACO  is  esta¬ 
blished  and  bounded  by  a  number  of  factors.  Included  are: 

a.  The  contracting  officer’s  warrant .  This  provides  a  basic  authority  and 
establishes  limits  such  as,  dollar  amounts. 

b.  The  FAR.  Part  42  lists  specific  functions  which  are  automatically 
authorized  for  performance  or  that  may  be  authorized  at  the  discretion 
of  the  PCO. 

c.  Letter  of  Contract  Assignment.  When  the  PCO  assigns  a  contract,  certain 
unique  authorities  may  be  assigned  or  v.ithheld. 

<1.  Statutory  Law.  For  the  most  part,  these  statutes  are  implemented  by  FAR 
and  the  DOD  supplement  thereto. 

e.  Law  of  Agency.  The  principal  (Government)  cannot  deny  the  agent’s 
authorized  acts. 

4.  Authority  of  the  TCO, 

The  contracting  officer  appointed  to  terminate  contracts  for  convenience,  and  for 
default,  when  found  in  the  best  interest  of  the  government,  according  to  FAR;  also,  to 
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enter  into  settlement  agreements  by  negotiation  with  the  contractor. 


\ 


5.  Definition  of  a  Contract. 

Contract.  A  contract  is  a  promise  or  set  of  promises  for  breach  of  which  the  law 
gives  a  remedy,  or  the  performance  of  which  the  law  in  some  way  recognizes  as  a  duty. 
Specifically,  a  contract  is  an  agreement  between  two  or  more  persons,  based  on  a  promise 
or  mutual  promises,  which  establishes  an  obligation  that  the  law  will  enforce. 

The  social  need  for  legally  enforceable  contracts  is  obvious.  The  efficient  conduct 
of  business  in  the  absence  of  enforceable  rights  and  obligations  (contracts)  would  Ik* 
impossible.  Unenforceable  promises  are  not  enough  to  insure  that  businessmen  will 
receive  raw  materials  or  finished  goods,  the  transport  needed  for  delivery  of  the  product 
to  the  market  place,  and  payment  for  goods  sold  and  delivered  at  the  time  and  place 
agreed  upon. 

Law  of  Contracts.  American  courts,  using  English  jurisprudence  and  practices 
arising  out  of  the  common  law,  enforce  the  rights  and  duties  arising  from  a  valid  con¬ 
tract.  The  law  may  provide  a  remedy  for  a  breach  of  contract  by  awarding  damages  as 
compensation  for  the  injury  suffered  as  a  result  of  the  breach. 

6.  Contract  Elements. 

A  contract  must  contain  the  following  elements  to  be  enforceable  at  law:  an  agree¬ 
ment  between  competent  parties  for  a  valid  consideration  to  accomplish  a  lawful  purpose 
with  terms  clearly  set  forth  in  the  form  required  by  law. 

Agreement.  Essential  to  any  contract  is  an  agreement,  that  may  be  defined  as  a 
demonstrated  mutual  assent  between  the  parties.  A  so-called  meeting  of  the  minds  must 
take  place  for  a  contract  to  come  into  being. 

The  agreement,  or  demonstrated  mutual  assent  of  the  parties  to  a  contract,  must 
consist  of  an  offer  and  an  acceptance.  The  term  offer  means  simply  a  proposal  to  enter 
into  a  contract.  The  person  making  the  offer  is  termed  an  offeror,  and  the  person  to 
whom  the  offer  is  made  is  known  as  an  offeree.  The  legal  effect  of  an  offer  is  to  create  a 
power  of  acceptance  in  the  offeree.  Therefore,  for  an  offer  to  be  valid,  it  must  lead  thi 
offeree  reasonably  to  believe  that  a  power  to  create  a  contract  is  conferred;  that  is,  vo 
reasonably  believe  that,  if  the  offer  is  accepted,  a  binding  agreement  will  exist.  No  partic¬ 
ular  formality  is  required  for  an  offer.  It  may  be  oral  or  written,  express  or  implied,  and 
it  may  be  made  by  words,  acts  or  forbearance,  or  by  a  combination  thereof. 

It  is  not  every  offer  that  may  form  the  basis  of  a  contract.  Only  those  offers  that 
meet  the  following  requirements  can  ripen  into  an  agreement  upon  due  acceptance.  The 
offer  must  be  communicated  to  the  offeree,  and  the  offer  must  be  definite  and  certain  in 
its  terms. 

An  offer  becomes  effective  at  the  time  that  an  offeree  becomes  aware  that  an  offer 
has  been  made.  If  it  is  an  oral  offer  it  takes  effect  at  the  same  time  that  the  offeree  hears 
the  proposition.  Written  offers  become  effective  when  the  offeree  receives  some  form  of 
written  communication.  The  amount  of  time  that  the  offer  is  to  remain  in  effect  may  be 
limited  by  the  offeror.  The  time  span  within  which  the  offer  must  be  accepted  will  com¬ 
mence  on  the  day  that  the  offeree  receives  the  written  offer  and  not  on  the  day  it  is 
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mailed.  If  the  letter  is  lost  in  the  mail,  or  for  some  other  reason  the  offeree  does  not 
receive  the  offer,  the  court  may  rule,  depending  upon  the  circumstances,  that  the  offeree 
must  be  given  an  opportunity  to  consider  the  offer.  If  the  offeror  does  not  specifically  set 
a  time  limitation  as  to  when  the  offer  must  be  accepted,  the  rule  holds  that  it  must  be 
accepted  within  a  reasonable  length  of  time.  Reasonableness  would  depend  upon  varying 
circumstances  including  the  thing  that  is  being  offered. 

Some  examples  of  terminating  an  offer  include: 

a.  an  offeree  may  expressly  reject  the  offer. 

b.  an  offeree  may  make  a  counter-offer  (as  such,  it  acts  to  reject  and  ter¬ 
minate  the  original  offer). 

c.  the  offeror  may  withdraw  (revoke)  the  offer  prior  to  acceptance. 

Competent  Parties.  An  enforceable  contract  cannot  be  made  by  a  party  with  no 
legal  capacity  to  contract.  The  legal  definitions  of  competency  are  beyond  the  scope  of 
this  chapter;  however,  some  clear  examples  of  incompetency  are:  intoxication  or  mental 
incompetency. 

Valid  Consideration.  A  promise  not  supported  by  consideration  imposes  no  duty 
on  the  promisor.  A  fundamental  concept  in  the  formation  of  a  contract  is  the  element  of 
bargain  and  exchange.  Consideration  is  the  price  paid  for  a  promise.  Consideration 
exists  when  something  of  value  must  be  given  by  the  promise  that  the  promisor  bar¬ 
gained  for  as  the  agreed  exchange  for  the  promise. 

Lawful  Purpose.  The  courts  will  not  recognize  a  contract  dealing  with  an  unlaw¬ 
ful  purpose.  A  contract  is  illegal  if  its  formation  or  performance  is  criminal,  tortious,  or 
contrary  to  public  policy.  As  a  general  rule,  the  law  will  not  aid  either  party  to  such  an 
unlawful  agreement. 

Terms  Clearly  Stated.  It  is  essential  to  the  enforceability  of  a  contract  that  its 
terms  be  sufficiently  clear  to  permit  interpretation  by  the  courts.  The  courts  will  apply 
various  rules  of  construction  to  interpret  the  meaning  to  clarify  any  conflict  or  ambi¬ 
guity. 

Form  Prescribed  by  Law.  The  legislatures,  federal  and  state,  have  imposed  certain 
additional  requirements  as  to  the  form  and  manner  of  certain  contracts.  Typical  of  these 
would  be  contracts  for  the  sale  of  real  estate,  which  are  generally  required  to  be  in  writ¬ 
ing.  Also,  a  Statute  of  Frauds  is  in  force  in  nearly  all  states,  which  requires  that  certain 
classes  of  contracts  be  in  writing  to  be  enforceable. 


♦. 
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7.  Definition  of  Agency. 

Agency  may  be  defined  as  a  relationship  based  upon  an  agreement  that  authorizes 
one  person  to  act  for  another.  The  law  of  agency  assumes  that  there  are  three  parties 
involved:  the  principal,  the  agent,  and  a  third  party.  The  principal  authorizes  the  agent 
to  act  as  an  intermediary  and  to  deal  directly  with  the  third  party  as  if  the  agent  were 
the  principal.  For  example,  contracting  officers  perform  as  representatives  (agents)  of  the 
United  States  Government  (the  Principal)  and,  in  so  doing,  they  deal  with  contractors 
(third  parties).  The  acts  of  the  agent  bind  the  principal  to  the  third  party  and,  also, 
give  the  principal  rights  against  the  third  party. 

Remember  that  an  agent  can  only  perform  an  act  that  the  principal  could  law¬ 
fully  do.  The  objective  sought  must  be  neither  criminal  nor  contrary  to  public  policy. 

The  primary  difference  between  an  agent  and  an  employee  is  that  the  employee 
normally  performs  some  kind  of  labor  or  service  for  the  employer  while  the  agent 
represents  (can  bind)  the  employer  in  dealings  with  third  parties.  An  individual  may 
wear  two  hats  and  perform  as  an  employee  and  as  an  agent;  this  is  an  area  that  may 
cause  many  problems.  An  unwary  contractor  may,  on  occasion,  assume  the  person  being 
dealt  with  is  an  agent  of  a  principal,  when  in  reality  the  person  is  only  an  employee.  Pro¬ 
ject  engineers,  technicians,  inspectors,  and  other  individuals  working  on  projects  for  the 
Government  may  make  statements  that  convey  the  impression  that  they  have  the 
authority  to  require  the  contractor  to  make  certain  changes.  The  individual  making  the 
statement  may  only  be  an  employee,  with  no  authority  to  make  changes.  An  experienced 
contractor  who  does  business  with  the  Government  knows  that  changes  to  his  contract 
may  only  be  made  when  authorized  by  the  Government’s  agent,  i.e.,  a  contracting  officer. 

8.  Reasons  which  may  qualify  a  contractor  for  contract  award. 

Responsiveness. 

To  be  considered  for  award,  a  bid  must  comply  in  all  material  respects  with  the 
invitation  for  bids  and  request  for  proposals.  Such  compliance  enables  all  bidders  or 
offerors  to  stand  on  an  equal  footing  and,  maintains  the  integrity  of  the  sealed  bidding 
and  competitive  proposal  methods. 

Responsible  —  reasonableness  of  price. 

The  contracting  officer  shall  determine  that  a  prospective  contractor  is  responsible 
and  that  the  prices  offered  are  reasonable  before  awarding  the  contract.  The  price 
analysis  technique  may  be  used  as  guidelines.  In  each  case  the  determination  shall  be 
made  in  the  light  of  all  prevailing  circumstances.  Particular  care  must  be  taken  in  cases 
where  only  a  single  bid  or  offer  is  received. 

Purchases  shall  be  made  from,  and  contracts  shall  be  awarded  to,  responsible 
prospective  contractors  only.  No  purchase  or  award  shall  be  made  unless  the  contracting 
officer  makes  an  affirmative  determination  of  responsibility.  In  the  absence  of  informa¬ 
tion  clearly  indicating  that  the  prospective  contractor  is  responsible,  the  contracting 
officer  shall  make  a  determination  of  non-responsibility.  If  the  prospective  contractor  is 
a  small  business  concern,  the  contracting  officer  shall  comply  with  Certificates  of  Com¬ 
petency  and  Determinations  of  Eligibility. 
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The  award  of  a  contract  to  a  supplier,  based  on  lowest  evaluated  price  alone,  can 
be  false  economy  if  there  is  subsequent  default,  late  deliveries,  or  other  unsatisfactory 
performance  resulting  in  additional  contractual  or  administrative  costs.  While  it  is 
important  that  Government  purchases  be  made  at  the  lowest  price,  this  does  not  require 
an  award  to  a  supplier  solely  because  that  supplier  submits  the  lowest  offer.  A  prospec¬ 
tive  contractor  must  affirmatively  demonstrate  its  responsibility,  including,  when  neces¬ 
sary,  the  responsibility  of  its  proposed  subcontractors. 

To  be  determined  responsible,  a  prospective  contractor  must  — 

(a)  Have  adequate  financial  resources  to  perform  the  contract,  or  the  ability 
to  obtain  them; 

(b)  Be  able  to  comply  with  the  required  or  proposed  delivery  or  perfor¬ 
mance  schedule,  taking  into  consideration  all  existing  commercial  and  govern¬ 
ment  business  commitments; 

(c)  Have  a  satisfactory  performance  record; 

(d)  Have  a  satisfactory  record  of  integrity  and  business  ethics: 

(e)  Have  the  necessary  organization,  experience,  accounting  and  operational 
controls,  and  technical  skills,  or  the  ability  to  obtain  them  (including,  as 
appropriate,  such  elements  as  production  control  procedures,  property  control 
systems,  and  quality  assurance  measures  applicable  to  materials  to  be  produced 
or  services  to  be  performed  by  the  prospective  contractor  and  subcontractors); 
and 

(f)  Be  otherwise  qualified  and  eligible  to  receive  an  award  under  applicable 
laws  and  regulations. 

0.  Contract  Administration. 

Prior  to  the  1960’s,  the  parent  organization  of  the  preaward  function  (Army, 
Navy,  or  Air  Force)  was  responsible  for  the  contract  administration  phase  of  each  con¬ 
tract  awarded.  The  inefficiencies  of  this  system  were  highlighted  by  a  special  study  (Pro¬ 
ject  60).  In  general,  duplicative  government  Contract  Administration  Organizations 
(CAO’s)  (a  combination  of  Army,  Navy,  and  Air  Force)  at  major  DOD  contractor  facili¬ 
ties,  each  with  its  unique  approach  and  procedures  to  the  contract  administration  phase, 
increased  the  cost  and  created  a  situation  that  required  the  contractor  to  comply  with 
many  different  agency  peculiar  requirements  which  were  often  in  conflict  with  each  other. 
To  eliminate  these  inefficiencies,  and  present  one  face  to  industry,  thereby  avoiding 
conflicting  agency  requirements,  the  DOD  reorganized  in  the  early  1960’s  to  the  organiza¬ 
tion  which  exists  today.  Specifically,  the  Defense  Supply  Agency  (now  the  Defense  Logis¬ 
tics  Agency)  was  created  to  perform  acquisition  functions  common  to  each  of  the  services. 
Of  the  many  responsibilities  of  this  agency,  administration  of  DOD  contracts  was 
assigned  to  a  newly  created  sub-agency  called  Defense  Contract  Administrative  Services 
(DCAS).  Since  its  creation,  DCAS  has  been  the  principal  government  organization  for 
contract  administration.  DCAS  provides  services  through  a  network  which  establishes 
geographic  areas  of  responsibility.  The  Continental  United  States  and  it’s  territories  are 
divided  into  9  separate  areas  of  responsibility.  These  areas  are  called  DCAS  Regions 
( DCASRs ).  DCASRs  currently  are  headquartered  at  Boston,  New  York,  Philadelphia, 
Atlanta,  Cleveland,  Chicago,  St.  Louis,  Dallas,  and  Los  Angeles.  Each  region,  in  turn,  is 
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geographically  divided  into  management  areas  ( DCASMAs )  and  DC  AS  Plant  Representa¬ 
tive  Offices  ( DCASPROs ).  It  is  at  this  level  that  day-to-day  contract  administration 
occurs.  DCASMAs  have  area  wide  responsibility  for  contract  administration,  unless  the 
amount  and  complexity  of  government  contracts  at  any  one  contractor  location  requires 
a  dedicated  team  of  contract  administration  specialists.  When  this  dedicated  work  force 
is  required,  a  Plant  Representative  Office  ( PRO )  is  established.  When  a  PRO  exists,  it 
has  total  responsibility  for  administration  of  all  DOD  and  NASA  contracts  performed  at 
that  location.  Simply  stated,  if  a  PRO  exists,  the  job  is  theirs;  otherwise,  the  DCASMA 
has  responsibility  for  all  other  contractors  in  their  area. 

10.  Functions  of  the  CAO. 

DCASMAs,  DCASPROs,  AFPRO,  NAVPRO,  and  ARPROs  each  have  the  follow¬ 
ing  functions  within  their  distinctive  organizational  structures.  How  much  each  function 
will  contribute  to  contract  administration  will  reflect  the  different  conditions,  different 
types  of  contracts  and  contract  work,  as  well  as  parochial  views. 

Engineering.  The  majority  of  non-local  purchase  contracts  is  for  items  designed 
and  manufactured  only  for  DOD.  Limited  production,  high  technology  and  the  rate  of 
change  to  meet  new  military  challenges  all  combine  to  create  a  relatively  high  level  of 
engineering  involvement  in  the  contracts.  CAO  engineering  personnel  often  work  in  close 
coordination  with  the  requirements/buying  activities. 

The  CAO  engineering  function  is  involved  in  proposed  engineering  changes  (con¬ 
tractor  or  government),  production  difficulties  relating  to  design,  and  surveillance  of  the 
contractor’s  engineering  and  configuration  management,  as  well  as  progress  surveillance 
of  engineering  tasks.  This  function  often  serves  as  the  trained  and  knowledgeable  eyes, 
ears,  and  hands  for  the  distant  buying  office  engineers,  as  well  as  engineering  translator 
for  other  functions  of  the  CAO. 

Transportation.  Supplies  must  be  shipped  to  the  proper  destination,  with  the 
appropriate  packaging  as  required.  The  transportation  function  monitors  the 
contractor’s  efforts  in  these  areas,  provides  technical  assistance,  and  manages  the  issuance 
of  Government  Bills  of  Lading  ( GBL ).  GBLs  are  the  documents  used  to  arrange,  and 
pay,  for  government  provided  shipment  of  supplies. 

Security.  Often  government  contracts  require  generation  of,  access  to,  or  use  of 
classified  information  and  items.  In  such  cases  the  contractor  must  have  a  security  pro¬ 
gram  acceptable  to  the  government.  The  CAO  therefore  must  monitor  the  program 
management,  and  provide  technical  assistance,  as  needed. 

Property.  Billions  of  dollars  of  property  owned  by  the  government  is  in  the  hands 
of  contractors.  Further,  he  contracts  may  state  that  specific  property  may  be  available 
as  a  condition  of  perfori,  xnce.  The  contractor  must  have  an  acceptable  system  for 
managing  and  accounting  or  such  property  and  the  C.AO  must  monitor  and  evaluate 
the  system.  Further,  the  CAO  provides  technical  assistance,  and  performs  those  appro¬ 
val  tasks,  required  to  maintain  and  account  for  government  property. 

Cost,  Price  and  Financial  Analysis.  Throughout  the  acquisition  process  there  is 
constant  need  to  analyze,  verify,  negotiate,  and  approve  contractor  cost  estimates.  This 
function  is  performed  both  when  the  CAO  has  decision  authority  and,  for  the  buying 
office  (in  conjunction  with  their  specialists),  when  the  buying  office  has  retained 
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authority.  Cost  and  price  analysis  normally  is  associated  with  the  actions  of  awarding, 
as  well  as  changing,  the  contract.  In  addition,  analysis  may  be  required  in  the  final  set¬ 
tlement  of  contracts.  On  one  hand,  it  is  necessary  to  determine  if  the  contractor  is 
strong  enough  to  carry  out  a  contract  and  on  the  other,  to  insure  the  contractor’s  finan¬ 
cial  management  system  assures  only  reasonable  costs  are  expensed  against  government 
cost  type  contracts. 

Production.  Contractors  must  plan  for  production  and  control  or  manage  the 
on-going  production.  The  government/contractor  relationship  requires  the  government 
to  monitor  the  management  of  these  functions.  Before  the  contract  is  awarded,  the 
Government  may  assess  whether  the  contractor  has  the  manpower,  machines,  available 
capacity,  and  management  to  perform.  During  performance  there  is  a  need  to  insure 
delivery  dates  will  be  met.  or.  if  difficulties  arise,  the  solutions  will  correct  discrepancies 
as  soon  as  possible. 

Quality.  A  level  of  quality  is  specified  in  every  contract.  Normally,  it  is  too 
expensive  to  test  everything.  Therefore,  included  in  the  contract  is  a  requirement  that 
the  contractor  organize  to  insure  the  item  is  produced  with  the  required  level  of  quality 
control.  The  CAO  must  monitor  the  contractors  quality  system  to  insure  it  is  adequate, 
and  is  properly  implemented.  Further,  the  CAO  normally  inspects  the  supplies,  insures 
conformance  to  the  contract,  accepts  title  (government  ownership)  and  authorizes  pay¬ 
ment. 

Contractor.  The  contracts  function  includes  several  tasks;  the  most  important  is 
to  act  as  the  authorized  on-site  agent  of  the  government.  The  ACO  can  legally  bind  the 
government  as  defined  by  delegation  of  authority  from  the  buying  office  and  in  accor¬ 
dance  with  the  FAR.  By  virtue  of  this  role,  the  task  of  coordinating  all  the  other  func¬ 
tions  becomes  part  of  the  contracting  function.  An  additional  task  oi  the  contracts  func¬ 
tion  may  be  to  review  the  contractor’s  contracting  policies,  procedures,  and  actions  to 
ensure  compliance  with  the  government  policies  incorporated  in  the  contract  clauses. 
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FIVE  ELEMENTS  OF  A  CONTRACT 


-  AGREEMENT  BETWEEN  TWO  PARTIES 

-  BOTH  PARTIES  COMPETENT  AGENTS 

~  VAT  .ID  CONSIDERATION 

-  LAWFUL  PURPOSE 

-  CLEAR  TERMS  AND  CONDITIONS 
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DCASR  GEOGRAPHICAL  BOUNDARIES  AND  COMPONENTS 
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TYPICAL  DEFENSE  CONTRACT  ADMINISTRATION  SERVICES  MANAGEMENT  AREA 
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LESSON  8 


LESSON  TITLE:  Communication  Exercise 
TIME:  1.5  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  communication  process  in  management. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

Describe  the  communication  process  in  a  management  setting. 

TOPIC  INTRODUCTION:  None. 

METHOD  OF  INSTRUCTION:  Communication  Exercise 
INSTRUCTIONAL  MATERIALS:  Communication  Exercise  handout 
AUDIO-VISUAL  AIDS:  None 
INSTRUCTIONAL  EQUIPMENT:  None 
REFERENCES:  None 

REQUIRED  STUDENT  PREPARATION:  None 
DISCUSSION  QUESTIONS: 

Refer  to  exercise  handouts  and  facilitator. 
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LESSON  0 


LESSON  TITLE:  Systems  Engineering 
TIME:  2  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know  the 
systems  engineering  process  as  it  is  practiced  in  DOD  Systems  and  the 
relationship  between  the  systems  engineering  process  and  the  design 
reviews  required  by  MIL-STD-I521. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Describe  the  seven  basic  steps  of  the  systems  engineering  process. 

b.  Describe  the  iterative  nature  of  systems  engineering. 

c.  Describe  the  general  activities  at  the  following: 

(1)  System  Requirements  Review  ( SRR ) 

(2)  System  Design  Review  (SDR) 

(3)  Software  Specification  Review  ( SSR ) 

(4)  Preliminary  Design  Review  ( PDR ) 

(5)  Critical  Design  Review  ( CDR ) 

(6)  Test  Readiness  Review  ( TRR ). 

TOPIC  INTRODUCTION: 

The  following  lessons  start  Block  2  of  instruction  in  SYS  100.  Block  2  takes  a  look 
at  the  many  different  functional  areas  you  have  to  be  aware  of,  familiar  with,  and  under¬ 
stand  in  managing  your  program.  In  some  cases,  some  of  the  information  presented  in 
this  block  will  be  an  expansion  of  material  presented  in  Block  1.  In  all  cases,  however, 
grasping  the  information  presented  in  Block  2  is  necessary  in  managing  your  program. 

Lesson  9  addresses  the  area  of  the  Systems  Engineering  process  as  required  in  the 
Department  of  Defense  development  programs.  As  our  weapon  systems  become  more  and 
more  complex,  we  need  a  structure,  or  process,  in  which  to  select  each  technological  alter¬ 
native  in  an  efficient  and  effective  way.  Systems  Engineering  provides  the  framework 
from  which  to  make  those  decisions.  The  steps  in  this  process  are  discussed,  and,  how 
they  may  be  applied  to  a  typical  program.  Finally,  with  the  Systems  Engineering  process 
providing  management  insight  into  technical  analysis  effort,  the  design  review  process  is 
discussed  as  a  way  for  the  government  to  get  visibility  into  technical  issues  for  problem 
identification  and  resolution. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article,  The  Systems  Engineering  Process,  by  Mr  Bill  Dean,  AFIT/LSY 

b.  Systems  Engineering  videotapes 

c.  Lesson  viewgraphs 
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AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  AFSCP  800-3,  A  Guide  for  Program  Management,  Chapter  8 

b.  MIL-STD-499A,  Engineering  Management 

c.  MIL-STD-1521B,  Technical  Review  and  Audits  for  Systems,  Equipment, 
and  Computer  Programs 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  The  System  Engineering  Process 

b.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  As  a  part  of  the  System  Requirements  Review,  you  are  reviewing  the  draft  Sys¬ 
tem  Specification  for  your  new  missile  system,  before  signing  it,  to  establish  a  Functional 
Baseline  for  the  program.  The  ILS  office  becomes  insistent  about  including  requirements 
that  the  contractor  has  apparently  left  out.  They  want  to  include  logistics-related  con¬ 
straints  about  accessibility,  common  support  equipment,  and  levels  of  maintenance  in  the 
specification. 

a.  Is  the  contractor  wrong  to  have  omitted  these  constraints  from  a  system 
specification?  Why? 

b.  If  this  additional  information  is  required,  what  is  the  normal  way  that  you 
would  get  the  contractor  to  include  these  requirements  in  the  System  Specification? 


2.  While  participating  in  the  System  Design  Review,  one  of  your  program  office 
engineers  identifies  a  potential  problem  with  the  contractor’s  design  process.  In  review¬ 
ing  the  requirements  being  generated  for  the  performance  of  the  missile’s  guidance  sub¬ 
system,  the  technology  appears  to  be  somewhat  dated,  if  not  antiquated.  She  has 
checked  the  backup  analysis  data  used  to  select  these  requirements  and  found  it  to  be 
very  sketchy  and  inconclusive.  She  has  also  queried  the  contractor’s  lead  designer  for  the 
guidance  subsystem  and  been  told  that  This  is  the  way  we  have  designed  all  of  our  missile 
guidance  subsystems. 

a.  In  your  opinion,  does  there  appear  to  be  a  real  problem?  On  what  do  you  base 
your  answer? 

b.  Do  you  feel  that  the  specification  is  adequate  and  ready  for  signing  to  establish 
the  Allocated  Baseline  for  the  guidance  subsystem? 

c.  What  should  you  do  to  get  the  contractor  to  rectify  the  situation? 
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3.  While  attending  a  quarterly  Program  Review  at  the  contractor’s  plant,  shortly 
after  the  beginning  of  the  Full  Scale  Development  phase  and  before  the  Preliminary 
Design  Review,  Mr.  D.  Zeiuei,  a  young  engineer  assigned  to  your  program  office,  comes 
to  you  with  a  problem.  He  has  been  talking  to  the  contractor’s  design  group  and  has 
determined  that  they  have  not  begun  detail  design  work  on  the  new  missile  you’re 
developing. 

a.  As  program  manager,  what  should  you  do  to  correct  this  situation? 

b.  When  should  the  contractor  be  required  to  accomplish  the  detail  design  work? 

4.  The  software  engineers  supporting  your  program  at  the  Critical  Design  Review 
are  upset  about  the  Contractor’s  detail  software  design  documentation.  It  consists 
almost  entirely  of  a  detailed  source  code  listing  (written  in  the  Ada  higher-order 
language)  with  the  backup  analysis  data  substantiating  the  selected  code  design.  The 
contractor  contends  that  he  has  provided  adequate  design  documentation. 

a.  Who  is  correct?  On  what  do  you  base  your  answer? 

b.  What,  if  anything,  will  have  to  be  done  to  correct  the  situation  and  to  get  the 
program  back  on  schedule? 


5.  As  the  first  set  of  operational  units  of  the  missile,  constituting  the  Initial  Opera¬ 
tional  Capability,  are  delivered  to  the  field,  your  program  office  representative  assigned 
to  the  Site  Activation  Task  Force  calls  you  with  a  problem.  At  least  30  percent  of  the 
support  software,  required  to  testy  and  maintain  the  missile  electronics,  is  not  available, 
so  it  will  be  extremely  difficult  to  maintain  the  equipment  and  will  require  many  more 
maintenance  manhours  than  originally  projected. 

a.  What  options  does  your  program  have  to  provide  support  for  the  operational 

units? 

b.  What  should  your  program  have  done  during  development  to  assure  that  the 
support  would  be  available? 

Chapter  9 


CDR 

Critical  Design  Review 

DBOD 

Data  Base  Design  Documents 

FCA 

Functional  Configuration  Audit 

FQR 

Formal  Qualification  Review 

IDD 

Interface  Design  Documents 

PCA 

Physical  Configuration  Audit 

PDR 

Preliminary  Design  Review 

SDDD 

Software  Detail  Design  Documents 

SDR 

System  Design  Review 

SRR 

System  Requirements  Review 

SSR 

Software  Specification  Review 

TRR 

Test  Readiness  Review 

9-3 


THE  SYSTEMS  ENGINEERING  PROCESS 


HISTORY 

In  the  past,  weapon  systems  were  relatively  simple  to  develop.  We  were  con¬ 
cerned  with  designing  the  primary  mission  equipment  (e.g.,  a  missile,  a  radar,  or  an  air¬ 
plane)  to  fulfill  a  certain  stated  need.  Maintenance  of  the  various  components  could  be 
accomplished  using  standardized  tools  such  as  screwdrivers,  wrenches,  pliers,  voltmeters, 
oscilloscopes,  and  signal  generators.  There  was  usually  a  requirement  for  the  develop¬ 
ment  of  a  few  new  tools  and  pieces  of  support  equipment  to  support  the  mission  items, 
but  that  effort  was  not  a  significant  part  of  the  development  effort.  Maintenance  person¬ 
nel  were  readily  available  and  highly  skilled.  The  primary  additional  effort  related  to 
support  involved  the  preparation  of  the  technical  manuals  which  provided  instructions 
on  how  to  diagnose  and  correct  problems  using  these  standard  and  special  tools  and 
equipment. 

In  the  last  twenty  years,  however,  weapon  systems  have  become  increasingly 
complex,  aided  by  increased  use  of  microminiaturized  electronic  circuitry  and  computer 
software.  Also,  available  manpower  has  a  smaller  percentage  of  the  highly  skilled,  career 
maintenance  personnel.  Systems  engineering  has  become  increasingly  important  as  a 
development  tool  because  of  its  ability  to  assess  the  viability  of  utilizing  various  techno¬ 
logical  alternatives  while  minimizing  the  risks  inherent  in  developing  a  complex  system. 
But,  most  importantly,  system  engineering  provides  a  tool  by  which  we  can  assess  the 
optimality  of  each  alternative  as  a  part  of  the  COMPLETE  SYSTEM  rather  than  just 
assessing  its  role  in  the  mission  equipment. 

DEFINITIONS 

The  term  system  has  many  connotations;  it  is  used  to  describe  everything  from 
environmental  processes  to  distributed  management  information  networks.  It  generally 
denotes  an  aggregation  of  a  number  of  different  elements  which  are  combined  to  achieve 
a  specific  goal.  In  DOD,  the  term  is  used  in  the  context  of  a  weapon  system  and  is 
defined  as: 

A  composite  of  subsystems,  assemblies  (or  sets),  skills,  and  techniques  capable 
of  performing  and/ or  supporting  an  operational  role.  A  COMPLETE  SYSTEM 
includes  related  facilities,  items,  material,  services,  and  personnel  required  for  its 
operation  [and  support J  to  the  degree  that  it  can  be  considered  a  self-sufficient 
item  in  its  intended  operational  (or  non- operational)  and/or  support  environ¬ 
ment.  (DOD-STD-480) 

The  heart  of  the  system  is  the  primary  mission  equipment  and  the  related 
software  that  actually  provides  the  operational  capability;  the  mission  items  have  always 
been  the  most  important  concern  in  developing  a  new  system.  Of  equal  importance  for 
new  systems,  however,  are  the  elements  of  support  equipment  and  support  software 
required  to  keep  the  system  in  operating  condition.  Because  of  the  highly  specialized 
designs  of  most  new  systems,  a  much  larger  percentage  of  the  maintenance  activity 
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requires  the  use  of  specialized  tools,  testers,  and  software  developed  specifically  for  this 
system.  The  system  also  includes  the  people;  their  professional  specialties,  and  the  level 
of  their  skills  in  those  specialties,  must  be  considered  in  identifying  the  various  alterna¬ 
tives  and  in  making  the  design  decisions.  The  system  includes  the  facilities  ranging  from 
production  lines  to  electronics  shops  that  will  be  needed  to  operate  and  maintain  the  sys¬ 
tem. 

For  purposes  of  system  design,  the  system  is  usually  divided  into  major  subsys¬ 
tems  and  components  in  order  to  ease  and  to  focus  the  management  of  the  design  effort. 
These  elements  are  usually  called  configuration  items  ( Cls ),  defined  as: 

An  aggregation  of  hardware/ software,  or  any  o f  its  discrete  portions,  which 
satisfies  an  end  use  function  and  t s  designated  by  the  Government  for 
configuration  management.  Cls  may  vary  widely  in  complexity,  size,  and  type, 
from  an  aircraft,  electronic,  or  ship  system  to  a  test  meter  or  round  of  ammuni¬ 
tion.  ( DOD-STD-48O ) 

System  engineering,  as  it  is  used  in  the  DOD  context,  can  then  be  defined  in  rela¬ 
tion  to  all  of  these  system  elements  as: 

The  application  of  scientific  and  engineering  efforts  to  (a)  transform  an 
operational  need  into  a  description  of  system  performance  parameters  and  a  sys¬ 
tem  configuration  through  the  use  the  an  iterative  process  of  definition,  syn¬ 
thesis,  analysis,  design,  test,  and  evaluation;  (b)  integrate  related  technical 
parameters  and  ensure  compatibility  of  all  physical,  functional,  and  program 
interfaces  in  a  manner  that  optimizes  the  total  system  definition  and  design;  and, 

(c)  integrate  reliability,  maintainability,  safety,  survivability,  and  human  and 
other  such  factors  into  the  total  engineering  effort  to  meet  cost,  schedule,  and 
technical  performance  objectives  (MIL-STD-499).  System  engineering  is  both  a 
technical  process  and  a  set  of  management  practices  which  must  be  applied 
throughout  the  system  life  cycle. 

THE  SYSTEMS  ENGINEERING  PROCESS 

System  engineering  has  established  a  rigorous  technical  analysis  process  to  be 
used  to  define  all  the  interrelated  constraints  for  all  the  elements  of  the  system,  be  they 
people,  logistics,  or  operational  constraints.  By  defining  all  the  system  performance 
requirements  or  design  constraints  in  our  contractual  technical  baselines,  the  contractor 
must  address  all  those  constraints  as  a  part  of  the  systems  engineering  analyses  and  deci¬ 
sions.  The  resultant  output  design  will  be  comprised  of  various  system  elements  which 
have  been  optimized  to  work  best  together.  It  is  likely  that  no  one  particular  element 
will  be  the  absolute  best  design  for  that  particular  function,  but'  it  is  the  best  comprom¬ 
ise  design  considering  all  of  the  various  system  factors. 

System  engineering  also  provides  management  insight  into  the  status  and  the 
acceptability  of  the  technical  analysis  effort.  Through  a  series  of  design  reviews,  and 
through  the  configuration  management  audit  activities,  the  government  periodically 
assesses  the  status  of  the  development  effort.  Through  this  review  process,  system 
engineering  assures  that  the  various  specialty  engineering  groups  are  kept  informed  of 
each  others’  activities  and  of  the  adequacy  of  their  efforts  to  date.  MIL-STD-499 
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provides  the  requirements  for  (systems)  engineering  management  that  we  can  levy  on  the 
contractors.  The  contractors  are  the  ones  who  do  the  systems  engineering  and  who 
develop  the  system  design. 

Steps  in  the  Process 

MIL-STD-499  identifies  numerous  activities  and  considerations  that  should  be 
included  in  the  systems  engineering  process.  These  can  be  separated  into  seven  basic  sys¬ 
tems  engineering  steps  which  comprise  the  process. 

-  The  first  step  requires  that  the  designers  review  the  complete  set  of 
requirements  for  the  particular  function  they  are  trying  to  design. 

-  With  those  requirements  in  mind,  the  second  step  requires  them  to  iden¬ 
tify  the  next  two  levels  of  functions  that  are  necessary  to  achieve  all  the 
requirements  for  this  function. 

—  Having  selected  all  of  the  functions,  the  third  step  requires  that  they  iden¬ 
tify  all  of  the  alternatives  available  to  accomplish  each  function. 

—  The  fourth  step  requires  them  to  prepare  a  requirements  sheet  for  each 
alternative  with  a  comprehensive  list  of  requirements  and  constraints  related  to 
that  alternative. 

—  In  the  fifth  step,  they  compare  the  advantages  and  disadvantages  of  the 
alternatives,  based  on  these  requirements  and  constraints. 

—  In  the  sixth  step,  they  select  the  alternative  that  seems  to  be  the  optimum 
compromise,  based  on  the  total  system  constraints,  for  this  particular  item. 

-  In  the  seventh  step,  the  contractor  places  the  requirements  sheet  for  the 
optimum  alternative  under  internal  control. 

Iterating  the  Steps 

Those  seven  steps  comprise  the  heart  of  the  systems  engineering  technical 
analysis  process.  But  that  isn’t  the  complete  process,  because  systems  engineering  is 
iterative;  the  seven  steps  are  repeated  over  and  over.  Thus,  the  requirements  that  were 
placed  under  control  in  the  seventh  step  of  the  current  iteration  are  the  ones  considered 
in  step  one  of  the  next  iteration.  The  process  is  not  unlike  eating  a  hamburger.  It’s  not 
advisable  to  try  to  eat  it  all  in  one  gulp.  If  you  try,  you  could  choke  on  it.  The  same 
principle  holds  true  for  systems  engineering.  If  the  contractor’s  engineers  try  to  address 
all  of  the  thousands  of  detailed  functional  elements  at  all  levels  for  the  system  and  make 
decisions  on  all  those  elements  at  once,  they’ll  be  overwhelmed.  The  contractor  has  to 
divide  the  system  into  more  manageable  pieces  and,  like  the  burger,  attack  it  a  piece  at  a 
time. 

The  early  stages  of  the  systems  design  process  involves  the  functional  decomposi¬ 
tion  of  the  system.  Using  this  concept  of  manageable  sized  pieces,  the  first  iteration  will 
address  the  two  highest  levels  of  functions.  The  contractor  will  use  the  seven  steps  to 
select  the  best  alternative  for  each  function  at  these  two  levels  and  will  place  the  related 
requirements  under  internal  control.  Assuming  that  there  were  twelve  functions  analyzed 
in  the  first  iteration,  then  the  contractor,  for  the  next  iteration,  will  conduct  twelve 
separate  design  analyses.  The  seven  steps  will  be  used  again  to  decompose  and  analyze 
subfunctions  for  each  of  the  twelve  alternatives  and  to  make  decisions  about  the 
optimum  alternative  approach  for  each  subfunction.  Each  of  these  twelve  alternatives 
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represents  a  manageable-sized  piece  for  the  purposes  of  systems  engineering.  Assuming 
that  there  were  ten  functions  lor  each  alternative  in  this  second  iteration,  then  the  third 
iteration  would  involve  120  separate  design  analyses,  representing  120  manageable-sized 
pieces.  The  iterations  will  continue  until  optimum  alternatives  have  been  selected  for  all 
of  the  functional  elements. 

In  the  later  stages  of  the  systems  design  process,  the  contractor  will  also  use  the 
seven  steps  of  the  technical  analysis  process  to  iteratively  analyze  and  optimize  the  detail 
design  for  each  function  already  selected.  The  direction  of  their  analysis  has  changed, 
however,  in  order  to  accomplish  the  detail  design  work.  The  engineers  will  start  with  the 
lowest-level  functions  and  work  up  through  the  levels  of  Cl  functions.  A  requirements 
sheet  was  placed  under  contractor  control  for  each  optimum  functional  alternative 
selected  during  the  functional  decomposition  and  analysis  of  the  system.  The  detail 
design  alternatives  for  the  function  will  be  selected  and  analyzed  based  on  those  require¬ 
ments.  In  this  case,  each  detail  design  alternative  has  certain  specific  capabilities,  as 
characterized  by  its  vendor.  Those  capabilities  will  be  compared  and  analyzed  based  on 
the  requirement  sheet  parameters.  Performance  in  specific  areas  will  be  analyzed  and 
compared  to  determine  which  of  the  candidate  design  alternatives  seems  to  be  the  best. 
Once  the  optimum  alternative  for  that  design  element  has  been  identified,  the  contractor 
will  take  control  of  that  detail  design  using  a  drawing,  a  digital  storage  medium,  or 
other  formally  released  and  controlled  documentation.  Having  completed  this  iteration, 
the  contractor  will  proceed  to  the  next  higher  function.  These  same  technical  analysis 
steps  will  be  used  to  determine  the  optimum  detail  design  for  each  system  funv-.ion.  The 
contractor  will  continue  upward  until  detail  design  decisions  have  been  made  for  all  func¬ 
tions  of  the  Cl  and  of  the  system. 

So  each  detail  design  iteration  is  very  similar  to  each  functional  decomposition 
iteration.  With  systems  engineering,  we  have  an  orderly  process  that  we  follow.  We 
don’t  choke  ourselves  by  trying  to  address  too  many  related  elements  at  one  time. 
Instead,  we  look  at  manageable-sized  chunks  of  the  design  with  each  iteration. 

DESIGN  REVIEWS 

As  a  part  of  the  overall  design  process,  the  government  periodically  must  review 
the  contractor’s  work  thus  far  to  assess  its  adequacy.  MIL-STD-I521  defines  specific 
design  reviews  and  configuration  audits  that  must  be  completed  as  part  of  the  systems 
design  process.  Among  other  functions  accomplished  at  these  events,  the  government 
will  review  the  specification  content  before  establishing  a  baseline  or  will  review  the 
design’s  ability  to  fulfill  the  baseline  requirements.  We  use  the  design  reviews  to  identify 
the  problems  as  early  as  we  can.  If  we  help  the  contractor’s  engineers  to  detect  areas 
where  the  requirements  or  the  design  need  to  be  revised,  they  use  less  time  and  money 
correcting  the  problems  at  this  time  than  they  would  if  they  had  to  return  later  to 
accomplish  the  redesign,  build  new  test  articles,  and  reaccomplish  some  or  all  of  the  test¬ 
ing. 
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System  Requirements  Review  ( SRR ) 

The  SRR  is  held  to  review  the  adequacy  of  the  system  requirements  as  defined  by 
the  draft  system  (or  top  item)  specification.  After  the  engineers  have  completed  two  or 
more  iterations  of  the  process  and  have  identified  requirements  related  to  four  or  more 
levels  of  functions,  sufficient  requirements  should  have  been  adequately  analyzed  and 
selected  to  allow  the  finalization  of  the  system  specification.  Before  we  accept  the  con¬ 
tents  of  the  specification  and  establish  the  functional  baseline,  we  need  to  make  sure  that 
the  government  technical,  logistics,  and  using  activities  completely  review  the  contents. 
MIL-STD-1521  requires  that  the  government  review  the  contents  of  the  system 
specification  at  an  SRR.  We  must  make  sure  that  nil  necvssmrv  system  requirements  ami 
constraints  are  adequately  defined.  In  addition  to  system  performance,  we  must  be  sure 
that  the  specification  includes  constraints  related  to  logistics  support,  personnel,  inter¬ 
faces,  and  existing  off-the-shelf  government  equipment.  We  also  review  the  adequacy  of 
the  verification  provisions  that  will  be  used  to  determine  that  the  system  requirements 
have  been  met.  During  the  review,  we  need  to  check  the  analysis  data  the  contractor  has 
used  in  arriving  at  these  specification  requirements.  The  review  of  the  analysis  data  can 
help  us  determine  the  superiority  of  the  requirements  (and  of  a  particular  alternative) 
selected  over  those  for  any  other  alternative. 

MIL-STD-1521  recommends  that  the  SRR  be  conducted  around  the  end  of  the 
concept  exploration  phase  or  the  beginning  of  the  demonstration/validation  phase  of  the 
program.  A  reasonably  complete  definition  of  the  systems  requirements  should  have  been 
accomplished  by  this  time.  The  government  should  have  made  decisions  related  to  the 
system  performance  and  should  be  ready  to  sign  the  system  specification  to  establish  the 
functional  baseline.  This  action  puts  the  system  requirements  under  government  con¬ 
tractual  control;  if  either  the  contractor  or  the  program  office  wants  to  change  the 
requirements  after  this  time,  an  engineering  change  proposal  will  be  required. 

System  Design  Review  (SDR) 

An  SDR  is  held  for  each  hardware  Cl  to  review  the  requirements  in  the  draft 
hardware  development  (performance  requirements)  specification  before  we  establish  an 
allocated  baseline  for  that  Cl.  As  a  result  of  the  completion  of  one  or  two  additional 
iterations,  the  engineers  should  have  analyzed  and  defined  more  functional  requirements 
for  many  additional  sub-functions.  These  should  be  sufficient  to  allow  finalization  of  the 
development  specifications  for  your  highest-level  CIs.  (On  the  other  hand,  more  itera¬ 
tions  will  be  required  before  SDRs  can  be  held  for  the  lower-level  CIs.)  Since  most  of  the 
development  and  testing  effort  is  accomplished  at  the  Cl  level,  we  need  to  make  sure  that 
the  requirements  and  the  tests  called  out  in  the  Cl’s  development  specification  are  ade¬ 
quate  and  complete.  During  the  review,  we  need  to  check  the  analysis  data  the  contrac¬ 
tor  has  used  to  decide  on  the  specification  requirements.  The  review  of  the  analysis  data 
can  help  us  determine  the  superiority  of  the  requirements  (and  of  a  particular  alterna¬ 
tive)  selected  over  those  for  any  other  alternative. 

MIL-STD-1521  recommends  that  we  establish  an  allocated  baseline  for  each  Cl, 
after  completion  of  its  SDR,  near  the  end  of  the  demonstration/ validation  phase  or  at 
the  beginning  of  the  full  scale  development  phase  of  the  program.  The  baseline  estab¬ 
lishes  a  contractual  agreement  between  the  government  and  the  contractor  about  the 
required  Cl  performance  and  about  the  tests  that  will  be  conducted  to  verify  that 
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performance.  The  baseline  provides  the  technical  basis  for  the  full  scale  development 
effort  as  the  contractor  finalizes  the  optimum  functional  design  of  the  Cl,  selects  the 
optimum  detail  design  for  each  functional  element,  and  finally  tests  the  detail  design  to 
be  sure  the  Cl  performs  to  the  baseline  requirements.  Any  changes  that  the  government 
or  the  contractor  wants  to  make  to  these  requirements  will  involve  submittal  of  an 
engineering  change  proposal.  The  number  of  such  changes  can  be  minimized  if  we  have 
done  our  homework  well  before  establishing  the  baseline. 

Software  Specification  Review  ( SSR ) 

The  SSR,  as  required  by  DOD-STD-2167,  is  held  for  each  software  Cl  to  review 
the  requirements  in  the  draft  software  (performance)  requirements  specification.  We 
must  review  the  requirements  in  the  software  requirements  specification  (and  in  the  inter¬ 
face  requirements  specification,  if  used)  before  we  establish  the  allocated  baseline  for  the 
software  Cl.  The  activities  and  documentation  at  the  SSR  are  very  similar  to  those  at 
the  SDR.  We  need  to  make  sure  that  we  agree  with  the  requirements  and  tests  in  the 
software  specification.  We  should  review  the  backup  analysis  data  to  make  sure  that  we 
agree  with  the  decisions  about  the  alternatives  and  requirements  the  contractor  made  as 
reflected  in  the  contents  of  the  specification.  As  a  result  of  the  SSR,  we  will  sign  the 
software  requirements  specification  and  establish  the  allocated  baseline  for  the  software 
CL  This  would  normally  happen  late  in  the  demonstration/validation  phase  or  at  the 
beginning  of  the  full  scale  development  phase. 

Preliminary  Design  Review  ( PDR ) 

The  systems  engineers  will  continue  this  iterative  process  of  functional  decompo¬ 
sition,  working  their  way  down  through  the  system  functions,  until  they  have  identified 
all  functions  and  adequately  characterized  them  in  the  requirements  documentation.  At 
this  point,  MDL-STD-1521  requires  that  we  conduct  a  PDR  for  each  Cl  before  the  con¬ 
tractor  begins  the  detail  design  process.  The  PDR  is  held  for  each  Cl  to  review  the  func¬ 
tional  design  analyses  completed  (and  the  design  functions  and  related 
requirements/constraints  selected)  by  the  contractor.  It  is  a  check  to  verify  that  all  of 
the  Cl’s  allocated  baseline  requirements,  including  interfaces,  have  been  addressed  and 
that  they  can  most  likely  be  met  or  exceeded  by  the  contractor’s  proposed  functional 
design.  The  PDR  would  normally  be  accomplished  during  the  first  few  months  of  the 
full-scale  development  phase. 

We  need  to  have  a  reasonable  degree  of  confidence,  based  on  that  functional 
design,  that  the  contractor  will  be  able  to  achieve  the  performance  required  in  the  allo¬ 
cated  baseline  for  that  CL  The  contractor  has  made  many  decisions  about  optimum 
functions  and  their  related  performance  parameters.  That  functional  design  is  considered 
to  be  the  best  for  our  needs.  We  should  look  at  the  contractor  analysis  data  for  the  vari¬ 
ous  alternatives  where  critical  performance  elements  are  involved  or  where  we  have  ques¬ 
tions  about  the  functional  alternatives  selected.  If  we  find  areas  where  the  contractor’s 
design  seems  to  be  weak,  or  where  it  seems  to  be  unable  to  meet  our  requirements,  we 
will  identify  them  to  the  contractor.  We’ll  ask  the  contractor  to  accomplish  additional 
design  work  in  that  area  or  to  provide  us  with  additional  data  about  the  area. 
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Critical  Design  Review  ( CDR ) 

The  CDR  is  held  for  each  Cl  to  review  the  details  of  the  specific  design  (gen¬ 
erated  by  the  contractor)  before  fabrication  of  test  hardware  or  detailed  coding  of  test 
software  is  begun.  Systems  engineering  has  to  consider  both  the  analysis  and  selection  of 
the  optimum  detail  design  alternative  based  on  the  requirements  sheet  for  this  function; 
however,  it  must  also  consider  the  additional  constraints  arising  from  previously-selected, 
lower-level  detail  design  elements.  The  CDR  is  a  check  to  assure  that  the  detail  design 
addresses  all  allocated  baseline  requirements  and  interfaces  and  can  be  reasonably 
expected  to  meet  those  baseline  requirements  for  the  Cl.  It  would  normally  be  accom¬ 
plished  a  few  months  after  the  PDR. 

The  detail  design  for  the  hardware  is  contained  in  drawings,  schematic  diagrams, 
and  related  documents.  For  software,  DOD-STD-2167  requires  that  Software  Detail 
Design  Documents  (SDUD),  Data  Base  Design  Documents  ( DBDD ),  and  Interface  Design 
Documents  ( IDD ),  plus  related  documents,  be  available  for  our  review.  MIL-STD-1521  is 
very  specific  in  requiring  these  software  design  documents  rather  than  the  line-by-line 
listing  of  the  code  (e.g.  in  FORTRAN,  ATLAS,  or  Ada). 

At  the  CDR,  we’re  concerned  with  reviewing  the  detail  design  on  the  hardware 
drawings  before  the  contractor  manufactures  actual  test  items.  For  critical  performance 
elements,  and  for  apparently  weak  areas  of  the  design,  we  should  look  at  the  analysis 
data  the  contractor  used  in  arriving  at  the  design  decisions.  If  there  are  discrepancies, 
we  want  to  work  them  out  while  the  design  is  still  on  paper.  We’ll  require  further  design 
work  in  that  area,  or  at  least  more  information,  to  revise  or  substantiate  the  detail 
design  in  that  problem  area.  If  a  discrepant  design  is  translated  into  hardware  or 
software  and  testing  begins,  it  will  eventually  cause  testing  delays  and  additional  expense 
to  redesign  it  and  remanufacture  it.  So  we  want  to  work  out  the  problems  as  early  as 
we  can. 

Test  Readiness  Review  ( TRR ) 

Losing  the  software  design  documents  reviewed  at  the  CDR,  the  contractor  will 
write  the  software  code.  Once  the  code  for  a  logical  unit  or  component  of  the  software 
has  been  written,  informal  tests  will  be  conducted  on  it  to  simulate  the  actual  conditions 
of  operation  and  to  find  out  whether  it  works.  However,  DOD-STD-2167  requires  some 
special  emphasis  on  the  coding  and  testing  of  the  software  CIs. 

The  Test  Readiness  Review  (TRR)  is  applicable  only  to  software  as  it  is 
currently  described  in  MIL-STD-1521.  It  is  to  be  held  to  review  the  results  of  the  infor¬ 
mal  testing  of  the  units  and  components  of  the  software  Cl  and  to  review  the  prepara¬ 
tions  for  the  Cl-level  testing.  If  the  initial  testing  revealed  major  problems  that  have  not 
been  corrected,  or  if  the  test  cases  and  test  procedures  for  the  Cl  testing  do  not  appear  to 
be  exhaustive  enough  to  fully  exercise  the  software,  then  the  software  Cl  testing  will  be 
delayed  to  correct  these  faults. 

Functional  Configuration  Audit  (FCA) 

The  contractor  will  conduct  the  qualification  testing  for  each  Cl  based  on  the 
contents  of  the  test  (quality  assurance)  section  of  the  development  or  requirements 
specification  for  that  CL  That’s  why  the  contents  of  that  test  section  of  the  specification 
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must  be  reviewed  so  carefully  before  the  specification  is  baselined.  Detailed  test  pro¬ 
cedures  will  be  written  and  submitted  to  the  government  for  approval.  We  will  check 
very  carefully  to  be  sure  that  the  test  procedures  reflect  all  the  required  tests.  We  need 
to  be  sure  that  the  necessary  instrumentation  is  identified  so  we’ll  get  the  data  that  we 
need  to  verify  the  performance.  After  the  contractor  has  obtained  our  approval,  the  test¬ 
ing  will  be  conducted  and  the  test  data  acquired.  During  the  testing,  if  some  instrumen¬ 
tation  is  unavailable  to  support  the  test,  a  change  to  the  procedures  may  be  requested  by 
the  contractor,  but  it  has  to  be  approved  by  our  on-site  test  representative.  After  the 
testing  is  completed,  the  contractor  will  compile  and  analyze  the  test  data,  prepare  for¬ 
mal  test  reports,  and  submit  the  test  results  to  the  government. 

The  Functional  Configuration  Audit  ( FCA )  is  held  for  each  Cl  to  review  the 
results  of  the  contractor’s  qualification  tests  and  to  verify  that  the  contractor’s  detail 
design  has  successfully  met  or  exceeded  the  performance  specified  in  the  allocated  baseline 
for  that  Cl.  We  verify  that  the  contractor  followed  the  test  procedures,  that  all  the  test¬ 
ing  was  completed  satisfactorily,  and  that  ail  the  required  data  was  gathered.  Govern¬ 
ment  engineers,  assisted  by  using  command  and  support  personnel,  will  review  all  the 
test  results  to  verify  that  the  contractor’s  design  meets  our  requirements.  If  we  find 
problems  in  the  actual  performance  capabilities,  we  cite  the  discrepancy  and  agree  with 
the  contractor  on  further  obligations  under  the  existing  contract  to  redesign  the  deficient 
part  or  to  conduct  further  testing.  The  FCA  would  normally  be  accomplished  near  the 
end  of  the  full  scale  development  phase. 

Formal  Qualification  Review  (FQR) 

The  FQR  may  be  held  in  lieu  of,  or  in  addition  to.  the  FCA.  It  is  held  to  verify 
the  successful  completion  of  all  system-  level  (multiple  Cl)  qualification  testing.  The 
FQR  will  be  used  when  the  contractor  is  unable  to  verify  all  elements  of  the  system  per¬ 
formance  at  the  Cl  level.  In  those  cases,  system-level  testing  will  be  required,  and  the 
FQR  is  held  to  verify  that  the  design  meets  the  functional  baseline  requirements.  The 
documentation  to  be  checked  and  the  tasks  to  be  accomplished  are  nearly  identical  to 
those  at  the  FCA.  The  difference  is  that  we  are  verifying  the  system-level  requirements 
(i.e.  the  functional  baseline).  If  we  find  problems  in  the  actual  performance  capabilities, 
we  cite  the  discrepancy  and  agree  with  the  contractor  on  further  obligations  under  the 
existing  contract  to  redesign  the  deficient  part  or  to  conduct  further  testing.  The  FQR 
may  be  accomplished  late  in  the  full  scale  development  phase  or  early  in  the  production 
phase.  Wherever  possible,  it  should  be  completed  before  the  PCAs  for  the  top-level  CIs 
of  the  system  are  held.  In  cases  where  all  of  the  system-level  requirements  have  been 
verified  during  the  testing  and  the  resulting  FCAs  for  the  individual  CIs,  it  is  not  neces¬ 
sary  to  hold  an  FQR. 

Physical  Configuration  Audit  (PC A) 

The  PCA  is  held  to  verify  that  the  design  documentation  (drawings,  parts  lists, 
software  listings,  etc.)  accurately  defined  the  qualified  production  configuration  as 
described  in  the  product  specification.  If  so,  we  will  take  control  of  that  design  by  sign¬ 
ing  the  specification  and  establishing  a  product  baseline.  For  hardware,  we  will  check  a 
sample  of  the  parts  in  the  production  unit  against  the  drawings  referenced  in  the  product 
specification  to  be  sure  that  they  are  the  correct  design.  For  software,  we  check  the 


9-11 


listing  in  the  specification  against  a  listing  taken  from  the  disk  or  tape  that  the  contrac¬ 
tor  plans  to  deliver.  The  PCA  is  normally  accomplished  early  in  the  production  phase 
when  the  first  production  item  is  ready  for  delivery.  An  FCA  must  be  completed  for  the 
Cl  prior  to,  or  concurrent  with,  the  PCA  for  that  Cl. 

In  addition  to  verifying  accurate  documentation  of  the  production  design,  we 
must  also  make  sure  that  the  engineering  release  system  provides  the  contractor  with 
adequate  control  of  the  documentation.  The  contractor  uses  the  engineering  release  sys¬ 
tem  to  control  the  manufacturing  documentation  and  to  control  and  record  the 
configuration  of  the  items  being  delivered  and  used  out  in  the  operational  arena.  We 
need  to  make  sure  that  only  the  most  current,  approved  documentation  is  being  used,  in 
order  that  only  the  most  current,  approved  design  is  being  delivered.  The  primary  idea 
for  the  PCA  is  to  make  sure  that  we  have  an  accurate  description  of  the  detail  design 
and  then  establish  a  product  baseline  to  take  control  of  that  detail  design.  From  that 
point  on,  the  government  controls  any  changes  to  the  detail  design  because  of  the  possi¬ 
ble  impact  on  units  and  support  elements  out  in  the  field.  We  have  to  have  control  over 
the  design  so  that  we  don't,  lose  control  of  our  logistics  support  system. 

INTERRELATIONSHIP  WITH  THE  WORK  BREAKDOWN  STRUCTURE 

In  accomplishing  the  functional  decomposition  of  the  system,  the  system  func¬ 
tions  can  be  depicted  by  a  hierarchical  chart  such  ns  a  block  diagram  or  an  indentured 
listing.  This  hierarchy  is  used  to  establish  the  Work  Breakdown  Structure  (WBS)  ele¬ 
ments  for  the  system.  The  WBS  is  a  product-oriented  family  tree  composed  of  the 
subelements  of  the  system  hardware  and  software  plus  the  service  and  data  activities 
that  are  an  inherent  part  of  the  project  engineering  efforts  during  the  development  of  a 
system.  The  WBS  will  be  used  for  allocating  budgets  for  manhours  and  dollars  to  be 
expended  on  the  project.  Most  commonly,  the  cost  and  schedule  information  is  budgeted 
and  tracked  against  the  WBS  elements  in  the  services  area,  not  in  the  system  sub¬ 
element  area,  and  the  totals  identified  only  against  the  top-level  item  or  system. 

SUMMARY 

System  engineering  is  both  a  technical  process  and  a  set  of  management  practices 
which  must  be  applied  throughout  the  system  life  cycle.  System  engineering  has  esta¬ 
blished  a  rigorous  technical  analysis  process  to  be  used  to  define  all  the  interrelated  con¬ 
straints  for  all  the  elements  of  the  system,  be  they  people,  logistics,  or  operational  con¬ 
straints.  By  defining  all  the  system  performance  requirements  or  design  constraints  in 
our  contractual  technical  baselines,  the  contractor  has  to  address  all  of  those  constraints 
as  a  part  of  the  systems  engineering  analyses  and  decisions.  The  resultant  output  design 
will  be  comprised  of  various  system  elements  which  have  been  optimized  to  work  best 
together.  It  is  likely  that  no  one  particular  element  will  be  the  absolute  best  design  for 
that  particular  function,  but  it  is  the  best  compromise  design  considering  all  of  the  vari¬ 
ous  system  factors.  But.  the  key  is  that  the  contractor  will  have  completed  the  design  of 
a  COMPLETE  SYSTEM. 
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SYSTEHS  ENGINEERING 

<  MIL-STD-499A  ) 


RDDRESS  ALL  SYSTEM  ELEMENTS 

-MISSION  EQUIPMENT  FIND  SOFTWARE 
-SUPPORT  EQUIPMENT  AND  SOFTWARE 
-FACILITIES 
-PRODUCIBIL ITY 
-MAINTENANCE  AND  SUPPLY 
-PERSONNEL  AND  TRAINING 

INTEGRATED  DESIGN  EFFORT 

-DEFINE  ALL  INTERRELATED  CONSTRAINTS 
-DESIGN  CONSIDERS  ALL  CONSTRAINTS 
-OPTIMUM  DESIGN  ELEMENTS  WORK  TOGETHER 


SYSTEH  ENGINEERING  STEPS 


1. 

2. 

3. 

4. 

5. 

6. 
7. 


REVIEW  REQTS  FOR  FUNCTION 
IDENTIFY  NEXT  TWO  LEVELS 
LIST  ALTERNATIVES  FOR  EACH 
LIST  ALL  RQTS  FOR  EACH 
COMPARE  ALTERNATIVES 
SELECT  BEST  ALTERNATIVE 
PUT  RQTS  UNDER  CONTROL 


REPEAT 


© 


C OHF  IGlJPflTIOM 
SOLUT  10IIS 
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SYSTEHS  ENGINEERING  IS  ITERRTIVE 

l'iERRTIVE= PERFORMED  RGRIN  RND  RGRIN 
START  AT  HIGHEST  LEVEL 

-IDENTIFY  OPTIMUtl  FUNCTIONAL  SOLUTIONS 
-CONTROL  RELATED  REQ'  TS/CONSTRA I  NTS 

REPEAT  FOR  NEXT  LOWER  LEVEL 

-IDENTIFY  OPTIMUM  FUNCTIONAL  SOLUTIONS 
-CONTROL  RELATED  REQ'  T S/CONSTRA I  NT S 

CHANGE  HIGHER  LEVEL  REQ' TS? 

-NEUER,  MORE  DETAILED  INFORMATION 

CONTINUE  WITH  ITERATIONS 

/r\conr  icvMmoM 


NOTORIZED  TOISPGRTflTION  SYSTEfl 

STHTEI1ENT  OF  OPERATIONAL  NEED 

-CARRY  FOUR  SIX-FOOT  PEOPLE  IN  COMFORT 
-AT  LEAST  TWENTY  CUBIC  FEET  OF  TRUNK  SPACE 
-INTERIOR  NOISE  LESS  THAN  62  DB  AT  60  MPH 
-INTERIOR  AIR-CONDITIONED  FOR  COMFORT 
-FUEL  ECONOMY  OVER  35  HWY/25  CITY 
-HIGH  RELIRBILITY/LONG  SERVICE  INTERVALS 
-EASY  ACCESS  TO  ELECTRONIC/MECHRNICAL  PARTS 
-AUTOMATIC  FAILURE  DIAGNOSIS/IDENTIFICATIOH 
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IDENTIFY  FIRST  TUO  LEVELS 


RLTERNRTIVES/RE8UIREI1ENTS 


ENGINE 


TRANSMISSION 


COMPARE  RLTERHRTIVES 

ADDRESS  EACH  ATTRIBUTE/CONSTRAINT 


SELECT  QPTIHUil  ALTERNATIVE 


ELEC 

GRS 

DIES 

COMPLEXITY 

1 

■EH 

2  1 

FUEL  ECONOMY 

1 

2 ; 

RCCELERRTION 

a 

1 

3 

STRRTING  ERSE 

l 

3 

RELIRBILITY 

a 

a 

tQp  SPEED 

3 

1 

2 

RETRAINING 

3 

1 

2 

RISK 

a 

2 

LIFE  CYCLE  COST 

3 

1 

18 

17 

19 

CONTROL  REQIJIREIIENTS  SHEETS 


© 


crmnci'f  fltlOH 

50LUT  IOMS 
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IDENTIFY  NEXT  TWO  LEVELS 


SYSTEM  REQUIREMENTS  REVIEW  (SRR) 

REVIEW  SYSTEM  SPECIFICATION 

-ALL  NECESSARY  SYSTEM  REQ'  TS/CONSTRA I  NTS 
-SUPPORT  AND  PERSONNEL  CONSTRAINTS 
-INTRA-  AND  INTER-SYSTEM  INTERFACES 
-SYSTEM  TESTS  TO  VERIFY  REQUIREMENTS 
-"TO  BE  DETERMINED"  <  TBD  >  REQUIREMENTS 

REVIEW  RNRLYSIS  DRTR 

-OPTIMUM  PERFORMANCE  CAPABILITIES 
-TECHNICAL /COST /SCHEDULE  RISKS  MINIMIZED 
-LIFE  CYCLE  COST  < LCC ?  MINIMIZED 

ESTRBLISH  FUNCTIONRL  BRSELINE 

-REQUIREMENTS  SUBJECT  TO  GOV'T  CONTROL 
-SYSTEM  SPEC  CHANGES  REQUIRE  ECP 


9-17 


IDENTIFY  NEXT  THQ  LEVELS 


SYSTEI1  DESIGN  REVIEW  (SDR) 

REVIEW  Cl  DEVELOPMENT  SPEC 

-FIPPLICRBLE  SYSTEM-LEVEL  REQUIREMENTS 
-NECESSARY  ADDITIONAL  ITEM  REQUIREMENTS 
-SUPPORT  AND  PERSONNEL  CONSTRAINTS 
-COMPREHENSIVE  TESTS  TO  VERIFY  ALL  REQ' TS 

REVIEW  RNRLYSIS  DRTR 

■  -OPTIMUM  PERFORMANCE  CAPABILITIES 
:  -LCC  AND  RISKS  MINIMIZED 

ESTRBLISH  RLLOCRTED  BRSELINE 

REQUIREMENTS  SUBJECT  TO  GOV'T  CONTROL 
-DEVELOPMENT  SPEC  CHANGES  REQUIRE  ECP 


©tour  ICOfflTlOW 

S0LU1 I  OHS 
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IDENTIFY  NEXT  TWO  LEVELS 


SOFTWRRE  SPEC  REVIEW  (SSR) 

REVIEW  Cl  DEVELOPHENT  SPEC 

-flPPL I CABLE  SYSTEM-LEVEL  REQUIREMENTS 
-NECESSRRY  ADDITIONAL  ITEM  REQUIREMENTS 
-PUNCTIONRL  INPUT/PROCESSING/OUTPUT  REQTS 
-COMPREHENSIVE  TESTS  TO  VERIFY  RLL  REQ' TS 

REVIEW  ANALYSIS  DATA 

-OPTIMUM  PERFORMANCE  CAPABILITIES 
-LCC  AND  RISKS  MINIMIZED 

ESTABLISH  ALLOCATED  BASELINE 

-REQUIREMENTS  SUBJECT  TO  GOV'T  CONTROL 
-DEVELOPMENT  SPEC  CHANGES  REQUIRE  ECP 

©COlir  1CWRTION 
S-OLIM  IOIIS 
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CONTINUE 

FOR  RS  NRNY 

ITERRTIONS 

RS  NEEDED 


IDENTIFY  ALL  FUNCTIONS 


©COHF  ICUPflTIOM 
SOLUT ions 


PRELiniNRRY  DESIGN  REVIEW  (PDR) 

REVIEW  FUNCTIONRL  DESIGN 

-H/W  FUNCTIONRL  BLOCK  DIRGRRMS/REQTS 
-S/U  TOP  LEVEL  DESIGN  DOCUMENT  ( STLDD ) 

COMPARE  TO  BASEL  I NE  REQ'  TS 

-MEETS  PERFORMANCE/ INTERFRCE  REQ' TS 
-MEETS  SUPPORT  AND  PERSONNEL  CONSTRAINTS 

REVIEW  ANALYSIS  DATA 

-LOCATE/ANALYZE  WEAK  AREAS 
-IDENTIFY  LIFE  CYCLE  COST  DRIVERS 

PROBLEM  AREA  — >  WRITEUP 
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©C ONP  KUPflT  1  ON 
SOLUT IONS 


DETAIL  DESIGN  PROCESS 

STDRT  UITH  LOWEST-LEVEL  FUNCTIONS 

-USE  REQU I REMENTS  SHEET  FOR  EACH  FUNCTION 
-IDENTIFY  DETAIL  DESIGN  ALTERNATIVES 
-ANALYZE  AND  COMPARE  DESIGN  ALTERNATIVES 
-RECORD  AND  CONTROL  BEST  ALTERNATIVE 

PROCEED  TO  NEXT  HIGHER  FUNCTION 

-REPEAT  THE  DETAIL  DESIGN  ANALYSIS 

CONTINUE  UP  TO  Cl  LEVEL 
CONDUCT  CRITICAL  DESIGN  REVIEW 

-FOR  EACH  CONFIGURATION  ITEM 

©i.  our  I  CUP  RT  1  OH 
> !*»L  H T  ions 


DETAIL  DESIGN  PROCESS 
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CRITICRL  DESIGN  REVIEW  (CDR) 

REVIEW  DETRIL  DESIGN 

-HRRDUARE  DETRIL  DRAWINGS 
-ELECTRONIC  CIRCUIT  SCHEMRTICS 
-SOFTWARE  DETRIL  DESIGN  DOCUMENT  ( SDDD  > 
-DATA  BASE  DESIGN  DOCUMENT  <  DBDD ) 

COMPARE  TO  BASELINE  REQ' TS 

-MEETS  PERFORMANCE/ INTERFACE  REQ' TS 
-MEETS  SUPPORT  AND  PERSONNEL  CONSTRRI NTS 

REVIEW  ANALYSIS  DATA 

-LOCATE  AND  ANALYZE  WEAK  DESIGN  AREAS 
-CHECK  ALTERNATES  ON  LCC  COST  DRIVERS 

PROBLEM  AREA  — >  WRITEUP 

(7\  CC'NF  IGUF'flT  I  ON 
V±/  SOLUT  IONS 


HKITE/TEST 

-•{test]- 
-[test]- 


SQFTWRRE  CODE 


UNIT 

CCDE 


UNIT 

CODE 


UNIT 

CODE 


UNIT 

CODE 


LOWER-LEVEL 

COMPONENT 

CODE 


{Test] 


TOP-LEVEL 

COMPONENT 

CODE 


j  TEST 

j  •  •  •  • 

LOWER-LEVEL 

s 

s 

COMPONENT 

TEST 

|  TEST 

CODE 

USE  DESIGN  DOCUMENTS  FOR  CODING 


© 


CWF1CUF AXIOM  : 
solux  i cits 
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TEST  READINESS  REVIEW  (TRR) 

REQUIRED  FOR  SOFTWARE  ONLY 
REVIEW  PRELIMINARY' TESTING 

-ITEM  AND  COMPONENT  LEVEL 
-SATISFACTORY  RESULTS  VS.  BASELINE 
-NECESSARY  CODING  CHANGES  ACCOMPLISHED 

REVIEW  PLANNED  Cl  TESTING 

-PROPOSED  TEST  CASES  ARE  ADEQUATE 
-TEST  PROCEDURES  ARE  ADEQUATE 

CONTRACTOR  READY  FOR  Cl  TEST 

-APPROVE  CSCI  QUAL  TEST  PROCEDURES 
-ON-SITE  REP  CONTROLS  CHANGES  eoTlfn 

C  UHf  l  VHP  AT  1  CHI 
Vi/  SUL U  T  ION? 


CONDUCT  QUflLIFICRTION  TESTING 

ANALYZE  Cl  TEST  REQ'  TS 

-FROM  SECTION  4  OF  Cl  DEVELOPMENT  SPEC 

PREPARE  TEST  PROCEDURES 

-DETAILED,  STEP-BY-STEP  PROCEDURES 
-TEST  CONDITION  DATA  REQUIRED 
-SPECIFIC  INSTRUMENTATION  TO  BE  CONNECTED 
-DATA  TO  BE  RECORDED  DURING  TESTING 

OBTAIN  GOVERNMENT  APPROVAL 
CONDUCT  THE  TEST  PROGRAM 
REPORT  THE  TEST  RESULTS 
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FUNCTIONAL  CONFIGURATION  AUDIT  (FCR) 

DUES  Cl  MEET  BRSELINE  REQ'  TS? 

-TESTING  FOLLOUEO  APPROVED  PROCEDURES 
-ALL  TESTING  SUCCESSFULLY  COMPLETED 
-DATA/REPORTS/ANALYSES  VERIFIED 
-DATA  VALID  FOR  FINAL  CONFIGURATION 

RECORD  FINAL  TEST  ITEM  CONFIG 

FORNHL  QUALIFICATION  REVIEW  (FQR) 

DOES  SYSTEM  MEET  BASELINE  REQTS? 
fc'RME  BASIC  PROCEDURES  AS  FCA 


PROBLEM  RREfl  — >  WRITEUP 


©c on r  iFUFqTicv 

SOI  UT  K  MS 


PHYSICAL  CONFIGURATION  AUDIT  (PCA) 

PRODUCT  SPEC  DEFINES  DESIGN 

-USE  EARLY  HARDWARE  UNI T/SOFTUARE  COPY 
-CHECK  DELIVERABLE  AGAINST  SPEC  DESIGN 
•COPY  LISTING  AGAINST  SPEC  LISTING 
*  HARDWARE  AGAINST  SPEC  REFERENCED  DWGS 

CHECK  ENGRG  RELEASE  SYSTEM 

-ONLY  CURRENT,  APPROVED  DOCUMENTS  IN  USE 
-OUTDATED  DOCUMENTS/VERSIONS  REMOVED 

ESTABLISH  PRODUCT  BASELINE 

'SIGN/AUTHENTICATE  PRODUCT  SPEC 

GOVT  CONTROLS  DETAIL  DESIGN 

©CONF  ICWBT10N 
SOLUT  I OtIS 
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REVIEU/RUDIT  PROCESS 

WRITE  TRSKS/1521  IN  CONTRRCT 
PLRN  SEQUENCE  WITH  CONTRACTOR 
CONVENE/CONOUCT  THE  MEETING 
DOCUMENT  THE  DESIGN  STATUS 
FOLLOW-UP  RND  CLOSE  OUT 


II ISSUE  SYSTEM 
REVIEU/flUDIT  SCHEDULE 


SYSTEM 

A.  A 

SRR  SF 

k 

R 

A 

FOR 

4 

A 

z 

\  A 

M'SSILE 

SI 

|)R  P  DR 

CDR 

PI 

:n  pcr 

GbIUfINCE 

A.. 

A 

A 

SDR  PDR  CDR 

FCR 

PCR 

GUIU  S/U 

A 

A 

A 

A 

SSR  CDR 

IRR 

FCfl 

PCR 

riOIUR 

i 

rehi  A 

Ak 

A 

A 

c 

>DR  PDR 

CUR 

FCR 

PCR 

mmi 

FULL  SCI1LE  DEVELOPIIEHI 

PRODUCTION 

»;  Mtir  m t  i  on 
"  t  i  "H  * 
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PCR 

MINUTES 

1  CERT  1FIC1ITI  OKS 

WRITE-UPS  1 

RCTIOH  ITEHS 


DI5QLRIMER5 
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LESSON  10 


LESSON  TITLE:  Integrated  Logistics  Support  ( ILS) 

TIME:  2  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  definition  and  importance  of  the  ILS  concept  and  the  elements  that 
make  up  ILS. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  he  able  to: 

a.  Define  ILS. 

b.  Describe  the  need  for  acquisition  logistics. 

e.  State  when  in  the  life  cycle  ILS  is  considered. 

d.  Match  the  elements  of  ILS  with  their  definitions. 

e.  Describe  the  role  of  the  DPMI,  in  the  AFSC  Program  Office. 

TOPIC  INTRODUCTION: 

Now  that  we  have  introduced  the  Systems  Engineering  process,  and  the  design 
reviews  that  allow  the  government  to  monitor  this  process,  how  do  we  plan  for  the  sup¬ 
port  of  that  technology  being  developed,  and,  ultimately  produced  as  a  weapon  system? 
The  answer  is  through  integrated  logistics  support.  Lesson  ID  addresses  the  concept  of 
Integrated  Logistics  Support  ( ILS)  and  how  it  relates  to  Department  of  Defense  acquisi¬ 
tions.  Obviously,  supportability  of  a  weapon  system  is  crucial  to  our  deployment  of  the 
weapon  system.  The  latest  acquisition  reforms  witnessed  the  addition  of  two  new  major 
milestones  geared  toward  analyzing  the  operational  supportability  of  weapons  systems 
versus  what  is  considered  efficient  and  effective.  Logistic  support  planning  begins  as  soon 
as  the  weapon  system  concept  is  defined  and  continues  throughout  the  system’s  life. 
This  lesson  expounds  on  the  elements  of  ILS,  and  the  role  of  the  Deputy  Program 
Manager  for  Logistics,  with  regard  to  the  supportability  concept. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article:  Integrated  Logistics  Support,  by  (’apt  Andrews,  AF1T/LSY 

b.  ILS  videotapes 

c.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4”  tape  player 


REFERENCES: 
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a.  DOD  Directive  5000.39,  Development  of  Integrated  Logistics  Support 
for  Systems  and  Equipment 

b.  DOD  Instruction  5000.2,  Major  System  Acquisition  Process 

c.  AFR  800-8,  Integrated  Logistics  Support  (ILS)  Program 

d.  AFR  800-2,  Acquisition  Program  Management 

e.  AFR  57-1,  Operational  Requirements:  Operational  Needs,  Requirements, 
and  Concepts 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Integrated  Logistics  Support 

b.  Scan  lesson  view-graphs 

DISCUSSION  QUESTIONS: 

1.  A  new  program  has  just  been  approved  to  enter  the  concept 
exploration/definition  phase.  The  appropriate  product  division  has  been  assigned  the 
responsibility  for  the  development  and  acquisition;  a  System  Program  Office  ( SPO )  has 
been  formally  chartered  and  you  are  assigned  as  the  program  manager.  The  Program 
Management  Directive  (PMD)  directs  AFLC  to  identify  a  deputy  program  manager  for 
logistics  ( DPML )  to  support  your  program.  One  day,  in  walks  Maj  Ima  Loggy,  your 
DPMI,. 

a.  After  the  introductions  are  over  and  Maj  Loggy  has  been  familiarized  with 
the  basic  program,  what  is  your  first  responsibility  in  assimilating  the  logistician  into  the 
program  office? 

b.  Besides  the  management  responsibility  of  the  elements  of  logistics  as  assigned  by 
the  program  manager,  what  other  areas/disciplines  should  the  logisticians  be  responsible 
for  or  have  significant  involvement  in? 


2.  You  are  the  program  manager  for  a  new  aircraft  weapon  system.  Since  you  are 
responsible  for  its  supportability.  you  must  ensure  all  the  support  resources  are  available 
to  support  the  deployed  system.  Before  you  can  contractually  task  the  contractors  for 
these  resources  you  must  know  the  intended  logistics  support  philosophies.  What  are  a 
few  of  the  more  crucial  questions  that  must  be  answered  before  exact  logistics  support 
requirements  can  be  identified  and  acquired. 


CRS 

DODD 

I  CBM 

ILS 

ILSM 

LCC 

LSA 

0&M 

PHSS.T 

SG 

TOs 


Computer  Resources  Support 
Department  of  Defense  Directive 
Intercontinental  Ballistic  Missile 
Integrated  Logistics  Support 
Integrated  Logistics  Support  Manager 
Life  Cycle  Cost 
Logistics  Support  Analysis 
Operation  and  Maintenance 

Packaging,  Handling,  Storage  &  Transportation 
Support  Equipment 
Technical  Order (s) 
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INTRODUCTION  TO  ILS 


Integrated  Logistics  Support  (ILS)  begins  when  a  DOD  need  is  identified  in  a  SON, 
ROC,  or  other  form  of  direction.  ILS  follows  a  weapon  system  from  program  inception 
until  it  is  phased  out  of  the  USAF  inventory.  The  program  manager,  who  is  responsible 
for  ILS  planning  and  management,  will  usually  assign  ILS  responsibility  to  the  Deputy 
Program  Manager  for  Logistics  (DPMI),  and,  in  some  cases,  to  the  Integrated  Logistics 
Support  Manager  ( ILSM ).  The  ILSM  usually  works  for  the  DPML  and,  with  complex, 
major  programs,  there  may  be  hundreds  of  functional  ILSMs  working  for  one  DPML. 
Some  non-major  programs  may  have  an  ILSM  and  no  requirement  for  a  DPML.  In  all 
cases,  howeves,  the  ILS  effort  is  the  program  manager’s  responsibility  prior  to  PMRT. 
After  PMRT,  the  supporting  command,  (usually  AFLC),  will  assume  responsibility  for 
ILS  management  as  well  as  overall  program  management.  This  is  not  intended  to  mean 
that  other  members  of  the  program  office  are  released  from  ILS  planning.  Rather,  ILS 
provides  a  framework  for  all  program  office  members  to  synthesize  and  integrate  all 
events  leading  up  to  the  successful  generation  of  a  weapon  system. 

The  enormity  of  this  logistics  effort  demands  a  structured  technique  to  analyze, 
quantify,  and  integrate  the  totality  of  the  logistics  support  resource  requirements.  The 
system  that  DOD  has  employed  is  Logistics  Support  Analysis  (LSA).  LSA  is  simply  a 
vehicle  for  implementing  ILS  requirements  during  the  acquisition  process.  DODD 
5000.39,  and  MIL-STDS- 1388-1 A  and  2A,  stipulate  more  about  LSA,  but  the  focus  of 
this  course  will  be  on  the  characteristics  and  magnitude  of  ILS. 

ILS  has  become  increasingly  important  to  the  Air  Force  as  our  weapon  systems  have 
become  more  and  more  complex.  This  complexity  in  the  weapon  systems  has  made  our 
systems  more  difficult  and  expensive  to  maintain.  We  have  found  that  the  most  cost- 
effective  approach  is  to  design  our  systems  with  support  in  mind  early  in  the  systems 
acquisition  process. 

The  systems  acquisition  process  is  a  myriad  of  events  which  must  be  accomplished 
for  the  development,  production,  and  deployment  of  a  system.  When  viewed  from  a  life 
cycle  cost  (LCC)  perspective,  systems  go  through  sequential  cost  stages.  These  stages  are 
typically: 

a.  Research,  Development,  Test  and  Evaluation  ( RDT&E ) 

b.  Acquisition 

c.  Operation  and  Maintenance  ( O&M ) 

d.  Deactivation/Retirement 

When  looking  at  the  costs  associated  with  each  of  these  stages,  over  an  extended 
period  of  time,  it  has  been  discovered  that  the  O&M  cost  of  weapon  systems  has  steadily 
risen  to  a  point  where  they  now  consume  more  than  50%  of  the  system’s  total  LCC. 
This  will  certainly  vary  markedly  when  analyzing  individual  systems,  but,  when  viewed 
as  an  average  across  the  DOD  spectrum,  it  still  represents  a  real  concern. 

Further  impacting  system  LCC  is  the  timing  of  key  program  decisions  such  as: 
defining  the  operational  scenario,  establishing  quantitative  performance  requirements, 
quantifying  the  number  of  systems  to  be  fielded,  specifying  deployment  locations,  select¬ 
ing  a  maintenance  concept,  etc.  Studies  have  shown  that,  by  the  end  of  systems  con¬ 
cepts  studies,  70%  of  the  decisions  defining  total  LCC  have  been  made,  85%  by  the  end 
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of  the  system  definition,  and  95%  by  the  end  of  full  scale  deployment.  This  does  not 
mean  actual  expenditures;  it  infers  future  spending  has  been  committed  because  of  the 
decisions  that  were  made.  It  must  be  added  that,  once  these  decisions  are  made,  chang¬ 
ing  them  at  a  later  date  could  drastically  impact  program  costs.  It  becomes  necessary 
that  changes  be  evaluated  for  cost  versus  benefit  before  the  change  is  implemented. 

Knowirg  that,  on  the  average,  the  greatest  amount  of  total  LCC  dollars  are  spent 
on  O&M,  which  really  equates  to  logistics  support,  and  that  the  vast  percentage  of  total 
LCC  is  committed  early  in  the  acquisition  process,  it  becomes  apparent  that  logistics 
planning  must  begin  at  the  front  end  of  an  acquisition  program.  The  remainder  of  this 
article  will  deal  with  the  process  of  integrated  logistics  support  ( ILS ). 

INTEGRATED  LOGISTICS  SUPPORT  (ILS) 


In  order  to  understand  ILS  it  is  necessary  to  familiarize  yourself  with  the 
definition  of  Acquisition  Logistics.  It  is  The  process  o j  systematically  identifying  and 
assessing  logistics  alternatives,  analyzing  and  resolving  ILS  deficiencies,  and  managing  ILS 
throughout  the  acquisition  process.  Acquisition  logistics,  then,  is  a  generic  term  identify¬ 
ing  and  describing  the  overall  logistics  function  within  which  ILS  is  the  predominant 
activity.  If  this  is  so,  then  what  is  ILS?  Department  of  Defense  Directive  (DODD) 
5000.39  describes  the  ELS  program  as: 

A  disciplined,  unified  and  iterative  approach  to  the  management  and  techni¬ 
cal  activities  necessary  to: 

a.  Integrate  support  considerations  into  system  equipment  design. 

b.  Develop  support  requirements  that  are  related  consistently 
to  readiness  objectives,  to  design,  and  to  each  other. 

c.  Acquire  the  required  support. 

d.  Provide  the  support  during  the  operational  phase  at  minimum  cost. 

What  is  this  definition  telling  us?  First,  it  stipulates  that  the  entire  ILS  process, 
when  used  on  a  program,  must  be  diligently  applied  ( disciplined ).  No  two  acquisition 
programs  are  alike  and,  likewise,  no  two  ILS  programs  in  support  of  an  acquisition  will 
be  alike.  However,  all  logistics  elements  must  be  evaluated  for  program  applicability. 
When  it  has  been  determined  what  specific  elements  are  necessary  they  must  be  pursued 
methodically.  The  ILS  elements  are  described  individually  later  in  this  chapter.  Also, 
inherent  in  this  definition  is  the  uncompromising  need  for  the  ILS  process  to  be  per¬ 
formed  and  managed  as  a  single  entity  (Unified).  The  interrelationship  of  the  ILS  ele¬ 
ments  to  each  other  is  such  that  a  change  in  one  could  greatly  alter  requirements  in 
another.  This  impact  could  be  in  cost,  schedule  performance,  design,  or  even  the  very 
need  for  an  element  may  become  questionable. 

In  order  for  the  ILS  program  to  be  effective,  it  must  be  periodically  and  systemati¬ 
cally  reviewed  and  updated,  as  the  program  progresses  ( iterative ).  Acquisition  programs 
are  extremely  dynamic.  Numerous  factors,  both  in  and  out  of  program  office  control, 
change  the  way  a  program  advances  through  the  acquisition  cycle.  From  the  results  of 
internal  trade-off  studies;  to  congressional  or  higher  headquarters  intervention;  to 
changes  in  requirements  from  the  using  command;  all  can  be  equally  valid  and  necessary, 
but  can  also  be  equally  devastating  to  the  timely  development  of  the  logistics  support 
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structure  for  a  system.  All  changes  must  be  evaluated  for  their  impact  on  the  ILS  ele¬ 
ments  and  the  other  logistics  processes  involved  in  the  ILS  program.  From  this,  plans 
must  be  revised  to  incorporate  the  change  with  minimal  disruption  and  expense  to  the 
program  and  to  the  system’s  future  logistics  support.  Simply  stated  the  four  functions 
identified  in  the  definition  of  ILS  mean: 

a.  As  systems  are  being  developed,  emphasis  must  be  placed  on  designing- 
in,  to  the  maximum  extent  feasible,  those  capabilities  that  improve  and 
enhance  logistics  support. 

b.  .As  the  logistics  support  package  for  a  system  is  being  planned, 
developed,  and  produced,  a  paramount  concern  must  be  to  obtain  the  right 
combination  of  logistics  elements  that  will  maximize  system  readiness  at 
minimum  life  cycle  cost.  It  is  not  only  necessary  that  each  logistics  element  be 
optimized  to  the  system  it  will  support,  but  they  must  also  be  optimized  to 
each  other. 

c.  Deciding  how  the  logistics  support  system  must  function,  and  its  compo¬ 
sition,  is  only  part  of  the  challenge.  In  most  programs,  industry  plays  the 
major  role  in  system  planning,  design,  and  fielding.  It  is  incumbent  upon  the 
program  logisticians  to  translate  logistics  requirements  into  contractual  require¬ 
ments  and  then,  more  importantly,  to  ensure  the  requirements  are  met.  We 
must  not  lose  sight  of  the  fact,  however,  that  a  significant  portion  of  the  logis¬ 
tics  resource  needed  to  support  a  system  may  come  from  existing  DOD  inven¬ 
tory.  Therefore,  equal  attention  and  coordination  must  be  given  to  the 
identification  and  acquisition  of  these  resources  through  government  agencies. 

d.  After  a  system  is  fielded,  the  logistics  support  structure  devised  for  it  is 
put  to  the  true  test.  It  would  be  unrealistic  to  expect  every  facet  of  the  logis¬ 
tics  infrastructure  established  for  a  system  to  perform  as  planned.  With  this  as 
an  accepted  given,  follow  on  actions  must  be  pursued  to  correct  deficiencies.  In 
addition,  we  can  expect  systems  to  be  modified  sometime  during  their  life  cycle. 

ELS  planning  does  not  end  until  a  system  is  retired  from  the  inventory.  So  the 
process  of  planning  and  implementing  logistics  support  will  continually  evolve. 

ILS  ELEMENTS 

ELS  elements  subdivide  the  ILS  program  into  manageable  functional  areas  and 
disciplines.  You  must  realize,  it  doesn’t  matter  whether  the  program  is  a  large  one,  like 
a  new  Intercontinental  Ballistic  Missile  (iCBM),  or  a  small  one,  like  a  new  helmet  for 
pilots,  all  logistics  elements  must  be  evaluated  for  applicability  to  a  program.  For  all 
practical  purposes,  what  changes  between  large  and  small  programs  is  the  depth  of  effort 
to  be  performed  in  each  element,  even  though  both  programs  may  have  incorporated  the 
same  elements  into  their  ILS  planning.  There  is  no  universal  agreement  concerning  what 
formally  comprises  the  ILS  elements  of  support.  The  element  descriptions  to  follow 
represent  the  DOD  perspective. 

1.  Maintenance  Planning.  This  is  the  process  conducted  to  evolve  and  establish 
maintenance  concepts  and  requirements  for  the  life  of  t  he  system.  In  includes,  but  is  not 
limited  to:  levels  of  repair;  repair  times;  testability  requirements;  support  equipment 


10-5 


needs;  manpower  skills;  facilities;  interservice,  organic  and  contractor  mix  of  repair 
responsibilities;  site  activation;  etc.  It  is  this  very  element  that  establishes  the  baseline 
for  planning,  development,  and  acquisition  of  other  logistics  support  elements.  As  you 
read  the  descriptions  of  the  remaining  ILS  elements  you  should  ask,  How  would  this  logis¬ 
tics  element  be  affected  by  the  maintenance  concept  for  the  system?  You’ll  soon  realize  the 
impact  in  nearly  all  cases  is  monumental.  It  goes  without  saying  that  the  future  holds 
interesting  challenges  for  maintenance  planners.  Even  now  systems  are  being  planned 
that  require  innovative  maintenance  approaches,  like:  fighter  aircraft  that  will  be 
launched  and  recovered  on  a  highway  rather  than  a  permanent  base;  mobile  ICBMs  in 
nearly  a  constant  state  of  movement;  and.  what  about  the  orbital  ninuucd  space  station: 
The  conventional  two  or  three  level  maintenance  concept  must,  by  necessity,  give  way  to 
a  new  dimension  of  maintenance  support. 

2.  Manpower  and  Personnel.  This  element  involves  the  identification  and 
acquisition  of  military  and  civilian  personnel  with  the  skills  and  grades  required  to 
operate,  maintain,  and  support  systems  over  the  systems  lifetime.  Early  identification  is 
essential.  If  the  needed  manpower  is  an  additive  requirement  to  existing  manpower  levels 
of  an  organization,  a  formalized  process  of  identification  and  justification  must  be  made 
to  higher  authority.  Add  to  this  the  necessity  to  train  these  persons,  new  and  existing, 
in  their  respective  functions  on  the  new  system,  and  the  seriousness  of  any  delays  in  the 
accomplishment  of  this  element  becomes  apparent.  In  the  case  of  military  requirements, 
manpower  needs  can.  and  in  many  cases  do,  ripple  all  the  way  back  to  recruiting  quotas. 

3.  Supply  Support.  This  element  consists  of  all  management  actions,  procedures, 
and  techniques  necessary  to  determine  requirements  to  acquire,  catalog,  receive,  store, 
transfer,  issue  and  dispose  of  spares,  repair  parts,  and  supplies.  In  laymen’s  terms  this 
means  having  the  right  spares,  repair  parts,  and  supplies  available  in  the  right  quanti¬ 
ties,  at  the  right  place,  at  the  right  time.  The  process  includes  provisioning  for  initial 
support,  as  well  as  acquiring,  distributing,  and  replenishing  inventories.  Keep  in  mind, 
an  aircraft  can  be  grounded  just  as  quickly  for  not  having  the  oil  to  put  in  the  engine  as 
it  can  for  not  having  the  engine. 

4.  Support  Equipment  (SE).  This  element  is  made  up  of  all  equipment  (mobile 
or  fixed)  required  to  support  the  operation  and  maintenance  of  a  system.  This  includes 
ground  handling  and  maintenance  equipment,  tools,  metrology  and  calibration  equip¬ 
ment,  and  manual  and  automatic  test  equipment.  During  the  acquisition  of  DOD  sys¬ 
tems,  we  are  expected  to  decrease  the  proliferation  of  support  equipment  into  the  DOD 
inventory  by  minimizing  the  development  of  new  support  equipment  and  by  giving  more 
attention  to  the  use  of  existing  DOD  or  commercial  equipment.  Most  programs  are  a 
mix  of  common  and  peculiar  (commercial  and  new  design)  support  equipment.  Equal 
emphasis  must  be  placed  on  the  identification,  funding,  and  acquisition  of  both.  A  pro¬ 
gram  office  may  Le  making  a  serious  mistake  if  they  think  the  SE  that  is  currently  in  the 
DOD  inventory  will  be  available  when  needed.  It  may  well  take  longer  to  get  some  of 
the  DOD  inventory  items  than  it  would  for  new  design  items  provided  by  the  contractor. 
Another  key  point  must  be  made.  The  availability  of  the  prime  system  can  be  heavily 
influenced  by  the  SE  used  for  fault  detection/isolation  and  repair.  Much  of  the  SE  used 
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today  are  repairable  items  themselves  and,  therefore,  require  the  timely  development  and 
fielding  of  a  logistics  support  system  for  the  SE  as  well.  This  means  that  SE  also  need 
maintenance  plans,  technical  orders,  spares,  facilities,  trained  manpower,  ts  own  support 
equipment,  etc.  It  should  thus  be  obvious  that,  if  the  support  equipment  isn’t  available 
because  it  cannot  be  repaired,  the  availability  of  the  prime  mission  equipment  could  be 
affected. 

5.  Technical  Data.  This  element  represents  recorded  information,  regardless  of 
form  or  character  (such  as  manuals  and  drawings),  or  scientific  or  technical  nature. 
Computer  programs  and  related  software  are  not  technical  data;  documentation  of  com¬ 
puter  programs  and  related  software  are.  Technical  Orders  (T.O.s)  and  engineering 
drawings  are  the  most  expensive  and,  probably,  the  most  important  data  acquisitions 
made  in  support  of  a  system.  It  is  the  T.O.s  that  provide  the  instructions  for  operation 
and  maintenance  of  a  system.  Without  them  it  may  be  difficult,  if  not  impossible,  to 
operate  and/or  maintain  the  prime  system  and  support  equipment.  Also  crucial  to  a 
system’s  LCC  is  engineering  drawings.  They  allow  competitive  reprocurement  of  spare 
and  repair  parts,  and  the  modification  of  systems,  which  in  the  long  run  should  minimize 
the  systems  LCC. 

6.  Training  and  Training  Support.  This  element  consists  of  the  processes,  pro¬ 
cedures,  techniques,  training  devices,  and  equipment  used  to  train  civilian  and  military 
personnel  to  operate  and  support  a  system.  This  includes  individual  and  crew  training, 
new  equipment  training,  initial,  formal,  and  on-the-job  training.  Though  the  greatest 
amount  of  training  is  accomplished  just  prior  to  the  fielding  of  a  system,  it  must  be 
remembered  that,  in  most  programs,  a  fairly  large  number  of  individuals  must  be  trained 
to  support  the  system  test  program,  which  can  occur  several  years  before  system  deploy¬ 
ment.  It  is  common  practice  for  trainers/training  devices  to  be  designed  and  produced  to 
support  a  recurring  training  program.  Since  a  trainer  is  an  end  item  in  itself,  it  too 
requires  the  establishment  of  a  logistics  support  structure,  as  was  necessary  for  support 
equipment  and  the  prime  system.  The  training  of  operating  and  maintenance  personnel 
can  be  seriously  impeded  if  trainers  are  not  usable  because  technical  orders,  spares,  sup¬ 
port  equipment,  facilities,  trained  operators,  etc.,  are  not  available.  The  less  than 
optimum  training  of  system  operators  and  maintainers  could  degrade  the  mission 
effectiveness  and  decrease  system  availability. 

7.  Computer  Resources  Support  ( CRS ).  This  element  encompasses  the  facilities, 
hardware,  software,  documentation,  manpower,  and  personnel  needed  to  operate  and 
support  mission  critical  computer  hardware/software  systems.  As  both  prime  systems  as 
well  as  support  equipment  increase  in  complexity,  more  and  more  software  is  being  used. 
The  expense  associated  with  the  design  and  maintenance  of  software  programs  is  so  high 
that  we  can’t  afford  to  not  manage  this  process  effectively.  It  is  a  general  standard  prac¬ 
tice,  within  each  service,  to  establish  some  form  of  a  computer  resource  working  group  to 
accomplish  the  necessary  planning  and  management  of  computer  resources  support.  As 
can  be  seen  in  its  definition,  this  element  does  cross  the  lines  of  responsibility  in  other 
ILS  elements  (i.e.,  facilities,  manpower,  etc.).  It  becomes  a  program  office  decision  as  to 
whether  all  the  resource  requirements  needed  to  support  this  element  are  managed  by  a 
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single  CRS  manager>  or  by  the  other  appropriate  ILS  element  managers>  with  the 
CRS  manager  monitoring. 

8.  Facilities.  This  element  consists  of  the  permanent  and  semi- permanent  real 
property  assets  required  to  support  a  system,  including  studies  to  define  types  of  facilities 
or  facility  improvements,  location,  space  needs,  environmental  requirements,  and  equip¬ 
ment.  Certainly  the  non-availability  of  facilities  can  be  just  as  damaging  to  a  system  as 
would  be  the  lack  of  spare  parts,  trained  personnel,  or  support  equipment.  The  main 
difficulties  associated  with  this  element  are  in  funding  and  management  responsibility. 
The  process  of  facility  design  and  construction  is  not  routinely  funded  or  managed  by 
the  program  office,  but  rather  by  civil  engineering.  This  could  be  base  level  civil 
engineers,  for  very  small  projects,  to  the  Army  Corps  of  Engineering,  for  projects  of  any 
significant  size.  Facility  funds  are,  in  the  vast  majority  of  cases,  authorized  by  Congress 
for  specific  projects  at  specified  locations  and  are  not  transferable.  The  funding  process 
takes  three  to  four  years  to  complete.  Once  the  process  has  started,  and  certainly  the 
closer  the  time  comes  to  actual  construction,  the  greater  the  impact  will  be  from  any 
change  to  facility  location.  A  last  minute  decision  to  deploy  a  system  to  a  different 
locale  may  well  require  extraordinary'  DOD  or,  even  Congressional  action  to  correct  facili¬ 
ties  delays.  Keep  in  mind,  facility  requirements  can  range  from  the  simple  addition  of  28 
volts  DC  power  to  an  existing  work  area,  to  the  design  and  construction  of  a  multimil¬ 
lion  dollar  facility.  In  either  case,  the  absence  of  the  necessary  capabilities  within  a  facil¬ 
ity,  or  the  absence  of  the  facility  itself,  will  be  adversely  felt  by  the  prime  system  the 
facilities  are  intended  to  support. 

9.  Packaging,  Handling,  Storage,  and  Transportation  ( P,Ii,S,&T ).  This  element 
is  the  combination  of  resources,  processes,  procedures,  design  considerations,  and 
methods  to  ensure  that  all  system,  equipment,  and  support  items  are  preserved,  pack¬ 
aged,  handled,  and  transported  properly,  including  environmental  considerations,  equip¬ 
ment  preservation  for  the  short  and  long  storage,  and  transportability.  Packaging  is 
more  than  cardboard  boxes  and  styrofoam  peanuts.  Some  items  require  special,  environ¬ 
mentally  controlled,  shock  isolated  containers  for  transport  to  and  from  a  repair  facility. 
A  single  package  like  this  can  cost  tens  of  thousands  of  dollars.  It  also  comes  as  no 
surprise  that  these  types  of  reusable,  repairable  containers  would  also  need  spare  parts, 
technical  data,  support  equipment,  etc.  for  their  own  support.  P,H,S,  &  T  may  be  a 
somewhat  overlooked  element,  but  it's  not  cheap.  The  reliability'  of  a  component  can  be 
significantly  influenced  by  how  it’s  packaged,  what  type  of  handling  equipment  and  pro¬ 
cedures  are  used,  where  and  how  it  is  stored  and  the  mode  of  transportation  used  to  get 
it  from  the  vendor  to  the  eventual  user.  Transportability,  on  the  other  hand,  means 
designing  into  a  system,  or  an  item,  the  ability  to  be  transported.  Trying  to  routinely 
transport  an  item,  such  as  an  intermediate  maintenance  avionics  test  station  that  was 
not  designed  to  be  transported,  can  result  in  the  inoperability'  of  the  test  station  and, 
therefore,  degradation  of  the  repair  capability  for  the  items  using  the  tester.  Transporta¬ 
bility  requirement  decisions  must  be  made  early  in  the  system  acquisition  process  and 
thoroughly  delineated  in  the  system  specification. 
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10.  Design  Interface.  This  is  the  relationship  of  logistics-related  design  parame¬ 
ters  to  readiness  and  support  resource  requirements.  The  logistics-related  design  parame¬ 
ters  include: 


a.  reliability  and  maintainability 

b.  human  factors 

c.  system  safety 

d.  survivability  and  vulnerability 

e.  hazardous  material  management 

f.  standardization  and  interoperability 

g.  energy  management 

h.  corrosion 

i.  nondestructive  inspection 

j.  transportability 

These  iogistics-reiated  design  parameters  are  expressed  in  operational  terms  rather 
than  inherent  values  and  specifically  relate  to  system  readiness  objectives  and  support 
costs  of  the  system.  Design  interface  really  boils  down  to  evaluating  all  facets  of  an 
acquisition  from  design  to  support  and,  operational  concepts  for  logistical  impacts  to  the 
system  itself,  and  the  logistic  infrastructure. 

ILS  MANAGEMENT 

The  explanation  provided  above  has  only  been  a  thumbnail  sketch  of  the  ILS  ele¬ 
ments.  Each  element  has  its  own  set  of  processes,  procedures  and  techniques  for  use  in 
satisfying  the  requirements  of  the  individual  element.  However,  one  must  not  forget  that 
the  I  in  ILS  stands  for  Integrated.  No  program,  and  more  specifically,  no  logistics  ele¬ 
ment  manager,  can  afford  to  be  so  myopic  in  the  management  of  their  individual 
element (s)  that  they  forget  about  the  extensive  inter-relationship  of  the  elements  to  each 
other.  The  mlminist ration  of  any  of  the  logistics  elements  is  a  two  fold  process;  the  indi¬ 
vidualized  management  and  attainment  of  the  element,  and  the  optimization  of  each  ele¬ 
ment  to  the  other  elements  applicable  to  a  program.  It’s  common  practice  across  DOD 
to  have  total  responsibility  for  a  systems  acquisition  levied  on  a  program  manager  or 
program  director.  These  responsibilities  are  cost,  schedule,  performance  and  supportabil- 
ity.  It  is  also  common  for  the  program  manager/ director  to  delegate  most,  if  not  all,  of 
the  responsibility  for  establishing  the  logistics  support  system  to  an  integrated  logistics 
support  manager.  This  person  usually  has  a  moderate  to  intensive  background  in 
acquisition  logistics  and,  depending  upon  the  size  of  the  acquisition  program,  will  have 
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other  logisticians  under  his  control  to  perform  all  the  tasks  necessary  to  identify,  plan 
and  implement  the  logistics  support  system. 

SUMMARY 

The  concepts,  processes  and  procedures  of  ILS  and  LSA  are  certainly  no  panacea 
for  all  the  ills  associated  with  the  acquisition  and  support  of  new  or  developing  systems. 
The  precepts  of  ILS  do  provide  a  process  which  can  more  thoroughly  examine  the 
requirements  for  supporting  equipment  vital  to  our  defense  needs.  This  thorough,  sys¬ 
tematic  approach  to  logistics  support  is  mandatory  in  the  prevailing  dinmte  of  cost- 
effectiveness.  The  optimum  balance  between  performance  and  life  cycle  cost  can  only  be 
achieved  by  including  logistics  support  considerations  in  all  phases  of  the  system's  life 
cycle. 
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DEFINITION  OF  1LS 


A  UNIFIED  AND  ITERATIVE  APPROACH  TO  THE  MANAGEMENT  AND 
TECHNICAL  ACTIVITIES  NECESSARY  TO: 

(1)  CAUSE  SUPPORT  CONSIDERATIONS  TO  INFLUENCE  BOTH 
REQUIREMENTS  AND  DESIGN. 

(2)  DEFINE  SUPPORT  REQUIREMENTS  THAT  ARE  OPTIMALLY 
RELATED  TO  THE  DESIGN  AND  TO  EACH  OTHER. 

(3)  ACQUIRE  THE  REQUIRED  SUPPORT. 

(4)  PROVIDE  FOR  THE  REQUIRED  SUPPORT  IN  TIIE  OPERATIONAL 
PHASE  AT  MINIMUM  COST. 
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MAINTENANCE 

FACILITIES 


Typical  System  Life  Cycle  Cost 
Distribution 


milestones 


lypicai  bystem 
Commitment 


WHEN  DOES  ILS  PLANNING  BEGIN? 


o  STATEMENT  OF  OPERATIONAL  NEED  (SON) 
o  JUSTIFICATION  FOH  MAJOR  SYSTEM  NEW  START  (JMSNS)* 
o  SYSTEM  OPERATIONS-  CONCEPT  (SOC)** 

[*  now  known  is  Mission  Need  Statement  (A/NS)) 

(**  now  known  is  System  Operational  Requirements  Document) 


HOW  DOES  ILS  PLANNING  EVOLVE? 


o  PROGRAM  MANAGEMENT  DIRECTIVE  (PMD) 
o  PROGRAM  MANAGEMENT  PLAN  (PMP)  SEC  TION  9 
o  INTEGRATED  LOGISTICS  SUPPORT  PLAN  (ILSP) 
o  INTEGRATED  SCPPORT  PIAN  (ISP) 


WHEN  DOES  ILS  PLANNING  END? 


o  WHEN  SYSTEM/EQUIPMENT  is  PHASED  OUT  OF  INVENTORY 


WHO  IS  RESPONSIBLE  FOR  ILS  PLANNING? 


o  BEFORE  PMRT  -  PROGRAM  MANAGER 
o  AFTER  PMRT  -  SYSTEM  PROGRAM  MANAGER 


ILS  OBJECTIVE 


to  held  achieve  am  si  stm\  a  required  readiness 

DOST  I  TIE  I T  MINIMI  M  LIFE  (  )  <  LE  COST 
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LESSON  11 


LESSON  TITLE:  Configuration  Management 
TIME:  2J>  hrs 

LESSON'  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  four  primary  functions  of  configuration  management  as  they  pertain 
to  the  system  acquisition  process. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  List  the  four  main  configuration  management  functions. 

b.  Define  what  constitutes  configuration  identification. 

c.  Identify  which  baseline  is  used  to  control  which  level  of  documentation 
detail. 

d.  State  the  purpose  of  the  Functional  Configuration  Audit  (FCA). 

e.  State  the  purpose  of  the  Physical  Configuration  Audit  (PCA). 

f.  State  the  purpose  of  configuration  control. 

g.  Identify  the  five  main  areas  of  emphasis  in  configuration  status 
accounting. 

Tone  introduction. 

V\ith  the  emphasis  on  integrated  logistics  support,  one  needs  a  method  or  discipline 
that  allows  acquisition  and  support  people  to  identify  and  document  the  characteristics 
of  a  development  program,  control  changes  to  those  characteristics,  and  record  and 
report  change  processing  and  implementation  status.  This  is  the  definition  of 
configuration  management.  It  would  be  very  difficult,  at  best,  for  support  planning,  and 
its  implementation,  if  we  did  not  know  what  the  weapon  system  could  do,  what  it 
looked  like,  what  it  could  interface  with,  how  hot  it  could  get,  etc.,  or,  as  referred  to  in 
this  lesson,  what  it  was  configured  like.  This  lesson  addresses  the  four  main 
configuration  functions,  the  different  baselines  and  audits  in  support  of  those  functions, 
and  the  concept  of  configuration  control  and  status  accounting. 

METHOD  OE  INSTRUCTION:  Lecture /Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article:  He  Still  Worry  About  Configuration  Management,  bv 
Mr  Bill  Dean.  AKIT/LSY 

I).  Configuration  Management  videotapes 
e.  Lesson  viewgraphs 


AUDIO- VISUAL  AIDS:  Chalkboard 


III 


INSTRUCTION \I.  EQUIPMENT:  Video  monitor  and  3/1  tape  player 


REFERENCES: 

a.  AFSCP  800-7,  Configuration  Management 
AFR  t>.r>-3,  Configuration  Mnnngenit  at 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  We  Still  li'ong  About  Configuration  Management 
h.  Scan  lesson  view-graphs 


DISCUSSION  QUESTIONS: 


1.  The  program  has  completed  most  of  the  Demonstration/ Validation  phase.  Col 
1.  M.  Boss,  the  program  director  for  your  new  missile  program,  is  concerned  about  estab¬ 
lishing  the  Functional  Baseline  this  early  in  the  program.  He  would  like  to  wait  until 
later  to  establish  it.  He  still  does  not  feel  sure  that  the  government  has  enough  informa¬ 
tion  to  really  know  what  the  system  requirements  are,  and  he  is  reluctant  to  have  to 
make  (and  pay  for)  sweeping  changes  to  the  requirements  later  via  Engineering  Change 
Proposal.  He  contends  that  we  can  wait  until  later  in  the  lull  Scale  Development  phase 
to  establish  the  baseline  and  continue  to  make  changes  to  the  requirements  without  need¬ 
ing  ECPs  and  without  having  to  pay  for  them. 

a.  When  is  the  Functional  Baseline  supposed  to  he  established?  Why? 

b.  Is  it  permissible  to  delay  the  establishment-  of  this  baseline  as  the  colonel  pro¬ 
poses''  Is  it.  wise? 

c.  What  impact  would  this  delaying  policy  have  on  the  contractor’s  design  effort7 
On  the  government's  control  over  the  contractor  s  design? 


2.  While  reviewing  the  draft  of  the  first  (of  many)  configuration  item  development 
specifications,  the  configuration  manager  notices  that  there  is  no  cross-referencing 
between  the  requirements  and  the  quality  assurance  provisions  in  the  specification.  She 
recommends  that  a  cross-reference  matrix,  similar  to  one  shown  in  MIL-STD-483,  be 
incorporated  In  each  specification.  The  contractor  says  that  the  matrix  is  not  required 
by  the  contract,  and  that  such  a  matrix  will  boost  the  price  of  each  specification  (there 
will  be  30  for  your  program),  bv  approximately  $3000. 

a.  How  will  the  matrix  benefit  the  program  office?  The  contractor? 

W  nul  l  it  be  worth  the  money  the  eontraetoi  is  quoting? 

I).  What  could  he  done  on  future  contracts  for  other  programs  to  be  sure 
that  a  matrix  will  he  in  the  specifications? 


3.  You  :ip-  I  member  of  (  R .  a  •  t  umriil  Executive  I’siel  reviewing  problem  areas 
Hmitim-,!  by  no  nil**  e-  ,>|  your  I-  urn  ;  ioiiai  (  >  •nlignrnl  h  >n  Audit  i.-am.  If  they  arc  \,did. 
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they  should  be  submitted  to  the  contractor  for  comment  and/or  correction.  In  this  case, 
Mr.  D.  Zeiner  has  reviewed  the  test  results  for  the  contractor’s  design  of  the  guidance 
computer;  while  the  design  has  met  the  specification  requirements,  Mr.  Zeiner  is  aware  of 
a  recent  development  in  microprocessors  that  is  much  faster  and  more  reliable.  In  his 
writeup,  he  wants  to  direct  the  contractor  to  incorporate  the  new  microprocessor  design 
into  the  missile  guidance  computer. 

a.  Should  the  Executive  Panel  approve  the  writeup  and  submit  it  to  the  contrac¬ 
tor?  Why? 

b.  What  should  Mr.  Zeiner  do  to  try  to  incorporate  the  new  microprocessor  into 
the  missile  guidance  computer? 


4.  After  the  Critical  Design  Review,  the  contractor  builds  a  few  prototype  units  of 
the  guidance  Cl  and  tests  them.  During  the  testing,  the  detail  design  of  the  inertial 
reference  unit  in  the  guidance  subsystem  proves  to  be  deficient  and  must  be  redesigned. 
The  contractor  submits  an  Engineering  Change  Proposal  for  the  redesign  and  retesting 
effort,  at  a  cost  of  $365, 000. 

a.  If  this  is  a  Fixed  Price  contract,  what  should  you  do  with  the  ECP?  Would  the 
process  be  different  if  it  is  a  Cost  Reimbursement  contract? 

b.  When,  in  the  program  life  cycle,  would  we  have  to  start  considering  these 
ECPs?  Why? 

[Acronyms  introduced  in  this  lesson,  and  their  description] 


Chapter  11 

ACSN  Advanced  Change/Study  Notices 

CM  Configuration  Management 

ECPs  Engineering  Change  Proposals 

TBD  To  Be  Determined 


WE  STILL  WORRY  ABOUT  CONFIGURATION  MANAGEMENT 

By  William  A.  Dean 

When  your  next  production  unit  is  delivered,  will  you  know  what  to  check,  to  be 
sure  it  is  the  correct  design?  When  the  first  unit  is  delivered  incorporating  that  new, 
high  reliability  black  box,  will  the  corresponding  technical  manuals  and  automatic  test 
equipment  be  available  to  support  it?  When  the  contractor  completes  the  qualification 
test  program,  can  you  be  sure  that  the  design  really  meets  your  mission  requirements?  If 
you’ve  ever  been  faced  with  these  concerns,  configuration  management  (CM)  has  some 
answers  for  you. 


WHAT  IS  CONFIGURATION  MANAGEMENT? 


CM  is  comprised  of  a  set  of  engineering  management  practices  and  procedures 

that  are  applied  in  four  basic  areas  of  emphasis: 

(1)  Configuration  Identification:  the  documentation  of  the  functional  and  physical 
characteristics  of  the  system  and  its  component  hardware  and  software. 

(2)  Configuration  Audits:  the  review  of  the  results  of  the  contractor’s  development  effort 
to  assure  that  government  requirements  have  been  fulfilled  in  the  design  and  to 
assure  that  the  detail  design  has  been  accurately  documented. 

(3)  Configuration  Control:  the  communication/decision  making  process  used  to  com¬ 
pletely  document  and  control  changes  to  the  contractually  binding  configuration 
identification. 


(4)  Configuration  Status  Accounting:  the  information  system  used  to  provide  traceabil¬ 
ity  of  the  documentation  and  delivered  units  and  of  the  changes  to  both. 

Those  arc  a  few  very  simple  words  that  describe  a  critical  process  that  must 
extend  over  the  entire  life  cycle  of  a  system.  But  there  is  nothing  mysterious  about  CM. 
The  practices  that  are  used  are  based  on  the  tailoring  of  common  sense  management 
practices  to  the  way  the  DOD  acquires  and  supports  its  weapon  system  hardware  and 
software. 


-  If  you  were  going  out  to  buy  a  bit  for  an  electric  drill,  you  wouldn't  buy  the 
first  one  you  saw.  You’d  have  to  think  first  about  whether  it  was  for  drilling  in  wood  or 
metal  or  masonry,  what  diameter  hole  you  had  to  drill,  and  what  was  the  maximum  size 
bit  your  drill  chuck  could  accept.  In  short,  you’d  think  first  about  what  you  wanted  it 
to  do  and  what  the  interface  constraints  were.  That’s  just  common  sense.  Likewise, 
when  the  DOD  goes  out  to  develop  a  new  missile,  we  first  must  define  what  we  want  it 
to  do,  so  that  the  contractor  will  design  a  missile  that  meets  our  needs.  (CONFIGURA¬ 
TION  IDENTIFICATION) 

--  If  you’re  building  a  new  house,  and  you’ve  asked  for  some  special  fixtures  or 
upgraded  carpeting  to  be  installed  in  it,  you  will  conduct  an  inspection  to  make  sure  the 
builder  complied  with  your  agreement.  Likewise,  when  the  missile  has  been  developed, 
we  will  have  to  check  to  make  sure  that  the  contractor’s  design  has  been  tested  to  prove 
that  it  meets  our  requirements.  (CONFIGURATION  AUDITS) 
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—  If  you’ve  ordered  a  relish  tray  to  be  delivered  on  Saturday  evening  for  a  party 
you’re  having,  the  caterer  can’t  deliver  finger  sandwiches  to  you  on  Wednesday  and 
expect  payment  for  them.  Business  law  (if  not  common  sense)  protects  you  in  that  type 
of  situation.  Likewise,  you  don’t  want  your  missile  contractor  to  delay  the  delivery  of 
production  units  or  change  the  design  of  any  of  the  installed  components  without  your 
permission.  (CONFIGURATION  CONTROL) 

—  If  you  go  to  the  Sears  Parts  Department  to  get  a  replacement  part  for  your 
garage  door  opener,  you  give  them  the  exact  model  number,  and  you  expect  that  they 
will  have  records  of  the  exact  replacement  part  number  (and  supplies  of  the  part)  you 
need.  Likewise,  when  a  component  on  the  missile  fails,  we  need  to  have  exact  records 
(part  numbers,  drawings,  and  manuals)  of  the  missile  configuration  so  that  we  can  iden¬ 
tify  and  obtain  the  part  we  need  to  fix  it.  (CONFIGURATION  STATUS  ACCOUNT¬ 
ING) 

CM  requires  careful  selection  and  acquisition  of  the  documentation  that  describes 
the  unit  or  system  we  are  buying.  The  documentation  provides  the  basis  for  determining 
whether  the  unit  meets  our  performance  requirements,  for  establishing  a  logistics  support 
system  for  the  system,  and  for  Government  acceptance  of  production  units.  Once  the 
documentation  has  been  placed  on  contract,  CM  requires  the  contractor  to  communicate 
with  the  government  and,  get  Government  agreement  before  making  any  change  to  the 
documentation.  In  communicating  information  about  the  change,  the  contractor  must 
summarize  the  total  impact,  especially  the  impact  on  the  logistics  support  system.  And, 
once  the  change  has  been  approved,  CM  requires  the  Government  to  track  the  implemen¬ 
tation  of  the  change  to  be  sure  all  new  hardware,  spares,  manuals,  etc.,  are  available  as 
proposed.  CM,  at  the  bottom  line,  is  required  to  assure  the  continuing  LOGISTICS 
SUPPORTABILITY  of  systems  in  the  Government  inventory. 

In  trying  to  understand  CM,  one  needs  first  to  understand  what  is  meant  by 
configuration.  The  physical  aspects  of  a  configuration  are  easy  to  understand.  Everyone 
understands  what  is  meant  by  the  physical  configuration  when  looking  at  the  actual 
hardware,  at  the  drawings  and  parts  lists  that  define  the  hardware  design,  or  at  the 
line-by-line  listing  representing  the  software  design.  On  the  other  hand,  few  people  con¬ 
sider  that  a  set  of  performance  requirements  and  constraints  in  a  specification  also  con¬ 
stitutes  a  configuration  —  the  functional  configuration.  But  early  in  the  development  of  a 
new  system,  before  the  design  and  testing  efforts  have  been  completed,  the  only  available 
description  of  the  system  is  in  terms  of  the  functional  (performance  requirements ) 
configuration.  Since  the  physical  design  will  evolve  based  on  these  requirements,  it  is  as 
critical  to  accurately  define  and  control  the  functional  configuration  during  development 
(and  throughout  the  life  of  the  system)  as  it  is  to  accurately  define  and  control  the  physi¬ 
cal  configuration  of  the  units  in  operational  use. 

The  basic  unit  of  CM  is  the  configuration  item  {Cl).  Essentially  all  of  the  CM 
functions  are  performed  at  the  Cl  level.  Specifications  are  written  to  document  the 
characteristics  of  each  Cl,  the  design  reviews  and  audits  are  performed  for  each  Cl, 
engineering  change  proposals  are  written  separately  for  each  Cl  affected  by  the  change, 
and  status  accounting  tracks  the  implementation  of  changes  to  each  Cl.  The  exception  is 
that  a  SYSTEM  specification  will  be  written  for  each  major  system  to  define  the  required 
performance,  and  a  Formal  Qualification  Review  will  usually  be  required  to  verify  that 
the  system  performance  has  been  met. 
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The  Cl  is  defined  as  an  aggregation  of  hardware! computer  programs,  or  any  of 
their  discrete  portions,  which  satisfy  an  end-use  function  .  ..  During  development  and 

qualification  testing,  CIs  are  usually  those  assemblies  of  components  (such  as  an  air-to- 
air  missile,  the  guidance  unit  in  the  missile,  and  the  guidance  software)  which  are  con¬ 
sidered  critical  during  development  to  successful  achievement  of  the  system  performance. 
By  designating  them  as  CIs,  we  are  saying  that  they  are  important  enough  to  deserve 
separate  requirements  documentation  (specifications  and  related  documents)  and  careful 
technical  monitoring  (reviews  and  audits)  during  design  and  testing.  Once  the  design  has 
been  qualified,  a  few  additional  CIs  may  be  selected,  for  logistics  reasons,  from  among 
the  major  components  of  a  Cl  (such  as  a  critical  black  box,  a  complex  printed  circuit 
board,  or  a  special  gyroscope  for  the  guidance  unit)  and  which  require  separate  documen¬ 
tation  and  control  in  order  to  facilitate  their  competitive  reprocurement  as  spares.  (Most 
spare  parts,  however,  do  not  have  to  be  CIs  in  order  to  be  competitively  reprocured). 

Configuration  Identification 

Configuration  identification  includes  the  specifications,  and  their  associated 
diagrams,  flow  charts,  drawings,  parts  lists,  etc.,  that  are  used  to  describe  the  functional 
and  physical  characteristics  of  a  Cl.  The  process  of  controlling  the  configuration 
identification  requires  the  Government  to  establish  baselines,  using  various  elements  of 
the  documentation,  which  are  expected  to  have  achieved  a  certain  level  of  definition 
(degree  of  maturity)  by  an  appropriate  milestone  in  the  program.  The  exact  time  of  the 
establishment  of  the  baselines  is  dependent  upon  the  type  of  program  involved,  but  the 
configuration  manager  should  have  a  key  input  in  the  timing,  and  in  the  type,  of  docu¬ 
mentation  required. 

The  functional  baseline  is  used  to  document  the  functional  (performance,  opera¬ 
tional,  logistics,  training,  etc.)  requirements/constraints  for  the  total  system.  It  usually 
consists  of  a  single  specification  (system  specification)  describing  the  essential  require¬ 
ments  for  the  basic  functional  elements  (both  hardware  and  software)  of  the  system. 
The  system  specification  will  usually  contain  all  of  the  requirements  and  constraints  that 
comprise  the  TECHNICAL  BASELINE  established  between  HQ  USAF/DOD  and  the 
program  manager  as  a  part  of  the  PROGRAM  BASELINE.  The  functional  baseline  is 
usually  established  at  the  end  of  the  Concept  Exploration  phase,  or  at  the  beginning  of 
the  Demonstration/ Validation  phase,  of  the  program.  It  establishes  the  TECHNICAL 
BASIS  for  the  contractor's  analysis  and  breakout  of  the  system  elements  and  their 
related  requirements.  It  represents  a  contractual  agreement  between  the  government  and 
the  contractor  concerning  the  expected  technical  outcome  of  the  development  process. 
The  requirements,  and  related  quality  assurance  provisions  in  the  system  specification, 
provide  the  basis  for  most  of  the  operational  testing  of  the  system. 

The  allocated  baseline  is  used  to  document  the  functional  (e.g.,  performance, 
operational,  and  logistics)  requirements  for  each  CL  (For  larger  systems,  there  may  be 
tens  or  hundreds  of  allocated  baselines  —  one  for  each  Cl  comprising  the  system.)  The 
allocated  baseline  is  really  an  expansion  of  the  (system)  functional  baseline  to  more  com¬ 
pletely  define  the  functional  characteristics  of  the  important  pieces  {CIs)  of  the  system. 
The  allocated  baseline  for  each  Cl  is  documented  in  a  (hardware  Cl)  development 
specification  or  (software  Cl)  requirements  specification.  The  requirements  in  the 
specification  are  tin-  basis  for  the  contractor's  design  of  the  Cl;  the  quality  assurance 
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provisions  in  the  specification  form  the  framework  for  the  qualification  (development, 
and  some  operational)  testing  of  the  Cl.  The  allocated  baseline  is  usually  established  at 
the  end  of  the  Demonstration/Validation  phase,  or  very  early  in  the  Full-Scale  Develop¬ 
ment  phase,  of  a  program.  The  Allocated  Baselines  establish  the  TECHNICAL  BASIS 
for  the  contractor’s  design,  development,  and  testing  of  the  Cl’s  prototype  production 
configuration  during  the  Full  Scale  Development  phase. 

The  product  baseline  is  used  to  document  the  detail  design  of  the  Cl  which  meets 
the  requirements  of  the  functional  and  the  allocated  baselines.  A  product  baseline  will  be 
established  for  each  Cl  after  the  contractor  has  successfully  demonstrated  that  it  meets 
the  specified  performance  (see  Functional  Configuration  Audit)  and  after  the  government 
has  conducted  a  design  verification  (see  Physical  Configuration  Audit)  of  a  production 
(or  production-like)  unit.  The  product  specification  requirements  define  the  physical 
design  of,  and  the  acceptance  criteria  (performance  values)  for,  each  production  item. 
The  acceptance  tests  required  by  the  quality  assurance  section  of  the  product 
specification  will  be  performed  on  each  production  unit  (or  lot  of  such  units)  and  must  be 
successfully  passed  before  the  Government  will  accept  the  unit  (or  lot).  The  product 
baseline  is  usually  established  early  in  the  production  phase  of  the  program,  when  a  pro¬ 
duction  unit  is  available,  but  it  may  be  established  at  or  near  the  end  of  the  Full-Scale 
Development  phase,  if  the  production  contractor  has  not  been  preselected.  The  Product 
Baseline  establishes  the  TECHNICAL  BASIS  for  the  manufacture  and  acceptance  of  the 
Cl  during  the  Production  phase  of  the  program. 

Configuration  Audits  (and  Design  Reviews) 

The  purpose  of  the  design  reviews  and  the  configuration  audits  is  to  review  the 
contractor’s  system  engineering  (both  design  and  test)  efforts,  as  progressive  increments 
of  the  configuration  identification  and  test  documentation  are  generated.  Although  the 
design  reviews  are  engineering  functions,  they  complement  the  establishment  of  the  base¬ 
lines.  Thus,  they  are  closely  tied  to  good  CM. 

--  The  Systems  Requirements  Review  ( SRR )  is  used  for  the  system  to  review  the 
adequacy  and  completeness  of  the  functional  configuration  identification  (system 
specification)  before  establishing  the  functional  baseline.  This  System  Specification  will 
often  carry  some  requirements  as  To  Be  Determined  ( TBD )  or  goals  through  the 
Demonstration/Validation  phase.  It  is  normally  accomplished  late  in  the  Concept 
Exploration/  Definition  phase  or  at  the  beginning  of  the  Concept  Demonstration/  Vali¬ 
dation  phase. 

—  The  System  Design  Review  (SDR)  (or  the  Software  Specification  Review  (SSJ?)] 
is  used  for  each  Cl  to  review  the  adequacy  and  completeness  of  the  allocated 
configuration  identification  (development  specification)  before  establishing  its  allocated 
baseline.  A  follow-on  SRR,  or  a  system-level  SDR,  may  also  be  used  for  the  system  in 
this  time  frame  to  finalize  the  TBD  requirements  and  goals,  before  their  incorporation  by 
ECP  in  the  System  Specification.  The  series  of  reviews  are  normally  accomplished  dur¬ 
ing  the  Concept  Deinonstration/Validation  phase  and  should  be  completed  early  in  the 
Full  Scale  Development  phase. 

--  The  Preliminary  Design  Review  (PDR)  is  used  for  each  Cl  to  address  its  func¬ 
tional  elements  and  their  related  performance  constraints,  as  selected  and  defined  by  the 
contractor’s  systems  engineering  analyses,  prior  to  proceeding  with  the  detail  design.  It 
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is  used  to  assess  the  chances  that  the  selected  functional  elements  will  meet  all  of  the  Cl’s 
specified  (allocated  baseline)  performance  requirements.  The  series  of  reviews  is  normally 
completed  early  in  the  FSD  phase. 

-  The  Critical  Design  Review  (CDR)  is  used  for  each  Cl  to  address  the 
contractor’s  detail  design  drawings  (or  Software  Detail  Design  Documentation)  prior  to 
releasing  them  for  manufacture/coding  of  qualification  test  (pre-production)  articles.  It 
is  used  to  assess  the  chances  that  the  selected  detail  design  elements  will  meet  all  of  the 
Cl’s  specified  (allocated  baseline)  performance  requirements.  The  series  of  reviews  is  nor¬ 
mally  completed  during  the  first  half  of  the  FSD  phase. 

-  The  Test  Readiness  Review  ( TRR )  is  used  for  each  software  Cl  to  review  the 
results  of  the  informal  testing  of  the  units  and  components  of  the  software  Cl  and  to 
review  the  test  procedures  to  be  used  to  test  the  software  Cl.  It  is  used  to  assure  that 
the  software  Cl  is  ready  for  Cl-level  testing.  The  series  of  reviews  is  normally  completed 
near  the  middle  of  the  FSD  phase. 

At  each  of  these  design  reviews,  an  additional  increment  of  system/CI  documenta¬ 
tion  has  been  generated.  The  purpose  of  each  review  is  to  detect  and  correct  errors  in 
this  increment  of  documentation  (and  to  realign  the  contractor’s  design  effort),  if  possi¬ 
ble,  before  further  Cl  design/testing  effort  is  undertaken  based  on  the  content  of  this 
increment. 

The  audits,  to  use  Webster's  definition,  are  a  check  of  the  final  statement  of 
account  of  the  development  program. 

-  The  Functional  Configuration  Audit  ( FCA )  is  used  for  each  Cl,  to  check  the 
results  of  its  qualification  testing,  in  order  to  verify  that  Cl  performance  meets  or  exceeds 
development  specification  (allocated  baseline)  requirements.  The  series  of  audits  is  nor¬ 
mally  accomplished  at  tlm  end  of  the  FSD  phase. 

--  The  Forma!  Qualification  Review  ( FQR )  is  used  for  the  system  to  check  the 
results  of  the  system-level  qualification  testing,  in  order  to  verify  that  all  system  elements 
meet  or  exceed  their  system  specification  (functional  baseline)  requirements.  It  is  held,  if 
required,  at  the  end  of  the  FSD  phase  or,  early  in  the  Production  phase. 

--  The  Physical  Configuration  Audit  (PC A)  is  used  for  each  Cl  to  verify  that  the 
detail  design  documentation  referenced  in  the  Cl's  product  specification  matches  the 
design  of  a  unit  being  delivered  to  the  government  and  to  verify  that  the  contractor’s 
engineering  (change)  release  system  is  able  to  control  the  release  of  changes  to  the  detail 
design  documentation.  The  series  of  audits  is  held  near  the  beginning  of  the  Production 
phase  when  a  unit  of  the  operational  configuration  is  available.  A  series  of  audits  may  be 
accomplished  at  the  end  of  the  FSD  phase  if  the  production  contract  is  to  be  competed. 

The  audits  are  used  to  verify  the  quality  of  the  contractor’s  full-scale  development 
effort  prior  to  the  Government’s  taking  control  of  the  detail  design  (with  the  Product 
Baseline)  and  authorizing  acceptance  and  operation  of  the  production  units. 

Configuration  Control 

Configuration  control  implies  the  control  of  the  baseline  documentation.  How¬ 
ever,  it  also  requires  communication  about  the  full  impact  of  proposed  changes.  Con¬ 
trary  to  popular  belief,  configuration  control  procedures,  including  the  use  of  forma! 
Engineering  Change  Proposals  ( F. CPs),  must  he  implemented  once  the  functional  baseline 


1 1-8 


(system  specification)  has  been  established.  When  the  allocated  and  product  baselines  are 
established  later  in  the  program,  formal  ECPs  are  then  required  to  be  submitted  and 
approved  before  changes  can  be  made  to  their  baselined  documentation.  Once  the  pro¬ 
duct  baseline  has  been  established,  even  minor  (Class  II)  changes  to  the  baselined  detail 
design  documentation  require  Government  agreement  before  they  may  be  implemented. 

Configuration  control  requires  that  sufficient  information  be  provided  in  the  ECP 
to  completely  document  all  impacts  of  the  change.  The  impact  on  all  system  elements 
and  contract  requirements  must  be  discussed.  During  the  development  phases,  the  ECP 
content  is  relatively  simple.  It  will  describe  specification  wording  changes,  describe 
changes  in  the  test  program  that  result  from  the  specification  changes,  and,  in  some 
cases,  describe  the  general  qualitative  impact  of  the  change  of  the  life  cycle  cost,  logistics 
support,  and  operational  capabilities  of  the  system.  During  the  production  and  opera¬ 
tional  phases,  much  more  information  must  be  provided  in  the  ECP.  A  detailed  descrip¬ 
tion  of  changes  in  part  design,  requirements  for  retrofit/rework  of  already  delivered 
units,  and  specific  impacts  on  the  logistics  support  system  (spares,  manuals,  tools,  etc.) 
must  be  included,  in  order  for  the  program  office  to  assess  the  total  impact  of  the 
change.  The  bottom  line  of  configuration  control,  during  production  and  operation,  is  to 
assure  the  continued  logistics  supportability  of  the  new  (and  the  old)  configuration,  once 
the  change  is  approved  and  implemented. 

Configuration  control  is  not  just  something  which  must  exist  between  the  Govern¬ 
ment  and  contractors.  Once  the  production  is  complete,  the  contractor  disappears  from 
the  picture.  However,  there  is  still  a  requirement  for  the  Government  Management 
Activity  to  control  changes  generated  by  a  Government  Engineering  (Design)  Activity. 
All  of  the  impact  information  (formerly  provided  by  the  contractor)  must  be  provided  by 
the  Design  Activity  and  the  proposed  change  approved  by  the  Management  Activity. 
Channels  for  official  documentation  and  approval  of  the  proposed  changes  are  similar  to 
those  used  when  the  contractor  was  involved.  These  channels  must  be  established,  and 
utilized,  if  configuration  control  is  to  be  maintained  for  the  delivered  items  throughout 
their  operational  life. 

Configuration  control  also  implies  the  management  of  the  number  of  changes 
being  submitted  by  the  contractor,  such  that  the  program  office  will  not  be  deluged  with 
ECPs.  Many  programs  require  the  contractor  to  obtain  permission  from  the  program 
office  (contracting  officer)  before  a  routine  ECP  may  be  prepared.  Preliminary  communi¬ 
cation  about  change  ideas  between  the  program  office  and  the  contractor  will  help  to 
reduce  the  costs  of  preparation  of  unwanted,  or  incomplete,  formal  proposals.  Prelim¬ 
inary  ECPs  and  Advanced  Change/Study  Notices  (ACS. Vs)  are  often  used  for  this  pur- 
|'i  v-tr. 


Configuration  Status  Accounting 

Status  accounting  provides  traceability  of  the  documentation,  units,  and  activities 
resulting  from  the  other  three  areas  of  CM.  However,  the  actual  role  of  status  accounting 
is  probably  the  least  understood  area  of  CM.  If  is  often  perceived  as  a  set  of  very  expen¬ 
sive  and  voluminous  computerized  reports  used  to  track  the  implementation  of  approved 
changes.  Large  programs  seem  to  need  them  and  pay  a  great  deal  of  money  for  them; 
small  programs  seem  unable  to  afford  them.  Actually,  however,  status  accounting  is  a 
management  function  which  requires  a  source  of  management  information:  the  reports 
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are  only  one  means  of  obtaining  this  information.  Using  this  management  information, 
status  accounting  policy  requires  that  we  maintain  traceability  of  the  following  CM 
activities: 

--  All  changes  must  be  carefully  tracked  from  the  time  the  idea  is  first  recorded 
officially  (in  an  Advanced  Change/Study  Notice,  contractor  or  program  office  letter,  prel¬ 
iminary  ECP,  formal  ECP,  or  other  document)  until  the  time  it  is  disapproved,  or 
approved,  and  officially  incorporated  into  the  contract.  The  intent  is  to  expedite  the  pro¬ 
cessing  of  changes  and  to  assure  that  changes  are  not  lost  or  delayed  during  processing. 

--  The  implementation  of  approved  changes  must  be  tracked  after  they  are  placed 
on  contract.  In  the  ECP.  the  contractor  has  identified  all  impacts  to  the  program  docu¬ 
mentation  and  has  provided  a  schedule  for  incorporating  all  changes  into  the  production 
line,  the  operational  units,  and  the  logistics  support  system.  Status  accounting  requires 
tracking  of  all  these  actions,  to  make  sure  they  are  accomplished  as  proposed,  or  to  iden¬ 
tify  problems  early  enough  to  develop  temporary  alternative  measures,  thereby  prevent¬ 
ing  disruption  of  the  operational/logistics  capabilities.  Sometimes,  status  accounting 
managers  require  very  detailed  change  implementation  tracking  information  to  be  pro¬ 
vided.  They  monitor  detailed  milestones  in  the  development  of  new/revised  manuals, 
acquisition  of  new  spares,  and  revision  of  support  equipment  software,  among  other 
impacts,  due  to  a  change  to  the  product  baseline.  For  retrofit/rework  changes,  they 
track  the  development  and  delivery  of  the  kits  of  modification  parts  and  the  associated 
installation/checkout  instructions.  In  m.  -t  cases,  they  record  the  actual  installation  of 
these  kits  in  operational  units. 

—  An  up-to-date  record  of.  and  historical  data  about,  identification  numbers  (e.g.. 
part  numbers,  model  numbers,  nomenclature)  and  document  numbers  must  be  main¬ 
tained  for  each  Cl. 

—  Tracking  of  all  approved  EC'Ps  for  each  Cl.  and  i  he  production  incorporation 
point  (serial  number  effect ivii.v)  of  the  change,  must  always  be  tracked. 

—  I  he  configuration  of  all  units  in  the  field  must  be  continuously  tracked.  In 
some  cases,  this  requires  only  part  number  control  of  the  components  installed  in  a 
configuration  item  or  system:  in  others,  there  must  be  part  number  and  serial  number 
(and.  sometimes,  time  of  operation)  control  of  certain  critical  components.  Differences  in 
the  configuration  of  similar  units  must  be  documented  and  tracked  to  eace  their  support 
and  modification.  Otherwise,  a  proliferation  of  unknown  quantities  of  units  with 
different  configurations  can  invalidate  the  program  documentation  and  complicate  the 
logistics  support  system. 

But.  whether  all  of  this  tracking  is  accomplished  by  reviewing  formal  reports,  by 
weekly  phone  conversations  with  the  contractor,  by  Government  plant  representative 
cheeks,  or  by  a  combination  of  nil  of  these,  the  tracking  of  these  elements  must  be 
accomplished.  The  amount  and  type  of  detailed  information  required  for  your  program 
is  vour  decision,  the  means  i>f  tricking,  will  no  determined  b\  vour  program,  but  the 
accomplishment  of  the  tracking  is  require  i. 
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Who  Needs  Military  Standards? 

As  a  program  manager  who  applies  CM,  you  should  understand  it  as  a  manage¬ 
ment  philosophy  and  should  understand  why  there  are  requirements  for  certain  events, 
documentation,  and  milestones  in  your  program.  The  actual  implementation  of  CM  will 
be  determined  by  the  size  and  complexity  of  your  program,  by  the  type  of  hardware  and 
software  involved,  by  the  phase  of  the  acquisition  cycle,  by  the  expected  production 
quantity,  by  the  expected  operational  deployment,  etc.  Sometimes,  schedule  or  money 
constraints  may  preclude  the  complete  accomplishment  of  every  CM  activity.  However, 
the  key  is  to  accomplish  at  least  the  INTENT  of  the  CM  activities  as  you  proceed  with 
the  program,  even  if  you  are  unable  to  accomplish  the  complete  scope  of  each  of  the 
activities.  Care  must  be  taken,  however,  in  deviating  from  the  basic  requirements  spelled 
out  in  the  military  standards. 

The  policy  in  the  DOD  Directive,  and  in  the  CM  Regulations  of  the  various  ser¬ 
vices  and  agencies,  prescribe  specific  CM  program  requirements  in  policy  language  and 
require  DOD  personnel  to  accomplish  certain  activities  in  the  CM  area.  However,  those 
requirements  cannot  be  placed  on  contracts.  The  military  standards  prescribe  specific 
CM  program  requirements  in  contractual  language  and  are  intended  for  contractual 
application.  They  have  been  written,  and  revised,  based  on  problems  encountered  (and 
lessons  learned)  in  other  DOD  programs.  The  requirements  in  the  military  standards  may 
be  tailored  to  delete  unnecessary  detail  from  the  program,  or  they  may  be  waived  and 
deleted  entirely  from  the  program  if  they  are  inappropriate  to  the  program.  Indiscrim¬ 
inate  tailoring  or  deletion,  however,  may  lead  to  insufficient  documentation  and  control 
of  system  design,  may  create  communications  problems  in  the  understanding  of  contrac¬ 
tual  tasks,  and  will  eventually  lead  to  problems  with  the  logistics  support  for  your  sys¬ 
tem. 

The  standards  provide  uniform  terminology  to  be  used  in  communicating  about 
CM  between  the  Government  and  most  DOD  contractors.  For  example,  if  I  speak  of  a 
Critical  Design  Review,  the  contractor  understands  the  intent  of  that  type  of  review  and 
will  know  where  to  go  (for  this  example,  MIL-STD-1521),  to  find  additional  detail  on 
what  type  of  documentation  will  need  to  be  available  and  what  activities  will  be  accom¬ 
plished.  On  the  other  hand,  if  I  speak  of  a  Technical  Documentation  Review,  the  con¬ 
tractor  will  need  a  detailed  description  of  it  in  the  statement  of  work  and,  even  then, 
may  not  fully  understand  its  purpose.  To  cite  another  example,  the  contractor  will  know 
what  information  is  to  be  included  in  a  Prime  Item  Development  specification  by  review¬ 
ing  MILrSTD-490,  and  we  know  what  to  look  for  in  reviewing  it.  But  the  contractor 
may  experience  problems  in  defining  the  required  performance  for  a  Cl  if  we  ask  for  a 
"Technical  Exhibit"  to  specify  the  requirements.  The  "exhibit"  may  include  too  few  (or 
too  many)  requirements.  It  may  not  provide  adequate  constraints  to  guide  the 
contractor’s  design  process,  or  it  may  unnecessarily  restrict  design  flexibility.  Or  the 
"exhibit"  may  omit  the  detailed  qualification  tests  contractually  defining  how  each 
requirement  will  be  tested  in  order  to  verify  the  adequacy  of  the  design.  By  following  the 
MIL-STD-490  requirements,  we  are  assured  of  specifying  adequate,  but  not  excessive, 
technical  requirements  for  the  system  and  its  component  CIs. 

The  military  standards  provide  for  a  common  understanding  of  contractual  tasks 
between  the  DOD  and  the  contractors.  The  tasks  associated  with  the  standards  are  well 
defined  and  understood.  If  this  is  the  first  Government  contract  for  a  contractor,  the  use 
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of  the  military  standards  will  help  the  contractor  to  understand  the  scope  ot  effort 
required.  After  the  completion  of  the  first  contract,  the  standards  allow  the  contractor 
to  utilize  an  established  data  base  in  estimating  the  work  effort  involved  in  performing 
similar  tasks  on  future  contracts. 

The  following  arc  the  principal  military  standards  utilized  to  implement  CM  on 
our  contracts.  Since  they  are  often  revised,  the  specific  revisions  are  not  shown  with  the 
basic  document  numbers. 

-  DOD-STD-480  (and  MIL-STD-481,  for  some  re  procurement  contracts)  estab¬ 
lishes  the  requirements  for  submittal  of  ECPs,  deviations,  and  waivers.  It,  also  defines 
the  amount  and  type  of  information  which  should  be  included  with  the  documents. 

—  MIL-STD-482  establishes  format  requirements  for  various  data  elements  and 
provides  a  guide  to  the  codes  for  data  elements  used  in  status  accounting  information 
systems. 

--  MIL-STD-483  (USAI  )  is  used  by  the  Air  Force  to  supplement  the  requirements 
specified  in  the  other  standards  and  to  provide  contractual  requirements  in  areas  not 
covered  by  the  other  standards. 

—  M1L-STD-490  defines  the  criteria  for  selection  of  various  types  of  program- 
peculiar  specifications  for  use  as  program  configuration  identification;  it  also  contains  an 
appendix,  for  each  typ<-  of  specification,  >n  M,hich  it  delineates  the  various  requirement® 
paragraphs  which  must  be  included  in  the  specification. 

—  MIL-STD-1521  (USAF)  contains  general  requirements  relating  to  the  accom¬ 
plishment  of  all  reviews  and  audits;  it  also  contains  an  appendix,  for  each  review  and 
audit,  in  which  it  spells  out  the  details  of  tasks  to  be  accomplished  and  documentation 
to  be  available  at  that  review  or  audit. 

These  are  the  primary  CM  standards;  their  tailored  application  to  various  pro¬ 
grams  must  be  accomplished  very  carefully.  The  tailoring  of  these  military  standards  for 
CM  should  be  accomplished  with  the  advice  of  your  configuration  managers.  They 
understand  the  needs  of  t  he  program,  as  well  as  the  philosophy  of  CM,  and  can  help  you 
to  specify  adequate  CM  tasks  and  activities.  (The  same  is  also  true  for  the  selection  of 
data  items  necessary  to  accomplish  or  document  the  tasks  required  by  the  military  stan¬ 
dards.)  Tailoring  guides  are  included  in  appendices  of  MIL-STD-1521  and  DOD-STD- 
480  to  aid  in  their  contractual  application. 

In  addition  to  these  primary  standards,  there  are  many  associated  documents. 
DOD-STD-IOO  (with  specification  DOD-D-IOOO)  is  available  for  guidance  in  obtaining 
engineering  drawings  and  associated  lists  for  the  programs;  it  also  provides  criteria  for 
controlling  changes  to  part  numbers.  Military  specification  MIL-S-83490  establishes  cri¬ 
teria  used  for  specifying  the  degree  to  which  program-peculiar  specifications  must  comply 
with  the  MIL-STD-490  format  and  content  requirements.  MIL-STD-499  provides 
requirements  for  the  contractor’s  (systems)  engineering  management  program;  it  is  sup¬ 
plemented  by  the  requirements  for  the  design  reviews  and  configuration  audits  in  MIL- 
STD-1521.  MIL-STD-901 ,  as  an  alternative  to  MIL-STD-490,  provides  the  format  and 
content,  requirements  for  military  (e.g.,  MIL- A- 12345)  specifications. 
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Problems  for  the  Program  Manager. 

Given  this  brief  description  of  Configuration  Management,  you  can  see  that  it  is  a 
common  sense  approach  to  a  critical  area  of  systems  program  management.  By  incor¬ 
porating  adequate  CM  into  your  program,  you  will  be  assuring  your  ability  to  define  and 
control  the  configuration  of  the  operational  units  and  to  facilitate  the  logistics  support  of 
those  units.  The  question  is,  Where  mil  you  find  the  person  with  the  qualifications  to 
accomplish  these  CM  tasks  for  you? 

For  many  years,  configuration  managers  were  characterized  as  Configuration 
Recorders,  required  merely  to  track  and  record  the  accomplishment  of  various  program 
activities  without  participating  in  the  initial  decisions  about  the  tasks.  Configuration 
managers  had  a  reputation  as  paper  pushers  and  as  road  blocks.  While  some  of  the  CM 
responsibilities  do  require  administrative  documentation  of  various  program  activities, 
and  adequate  control  of  the  configuration  does  require  time  to  accomplish  a  complete 
review  and  official  decisions  before  changes  to  the  contract  are  authorized,  practical 
management  demands  that  these  necessary  activities  be  accomplished.  Yet,  in  the  past, 
the  configuration  manager  has  received  little  recognition  or  praise  for  diligent,  painstak¬ 
ing  efforts  for  the  program  and  outstanding  management  advice  to  the  program 
manager.  Configuration  managers  often  have  the  greatest  awareness  of  the  overall  pro¬ 
ject  status  of  anyone  in  the  program  except  the  program  manager.  But  they  often  feel 
that  other  functional  managers  receive  more  recognition  and  are  more  likely  to  be  pro¬ 
moted.  So,  the  configuration  manager  will  spend  a  year  or  two  in  CM  learning  about 
program  management  and  then  transfer  to  some  other  functional  management  area 
where  the  promotion  potential  appears  to  be  better. 

If  there  is  to  be  effective  program  management,  there  is  a  need  to  change  this 
situation.  We  need  to  establish  a  viable  career  progression  for  the  configuration  manager 
if  we  are  to  retain  our  best  talent.  The  responsibility  for  program  recommendations  in 
the  CM  area  should  be  delegated  to  the  configuration  managers.  The  configuration 
manager  should  participate  in  the  program  planning  sessions  coequal  with  the  engineers, 
test  planners,  logisticians,  and  other  functional  experts.  The  experienced  configuration 
managers  have  the  expertise  in  that  functional  area,  the  familiarity  with  most  other 
functional  management  areas,  and  the  insight  into  the  program  needs  necessary  to  con¬ 
struct  a  suitable  CM  system.  But,  if  they  have  transferred  to  another  program  office  in 
some  other  functional  management  job,  you  won’t  be  able  to  get  the  help  you  need  in 
your  initial  program  decisions.  And  you  can’t  expect  a  brand  new  configuration  manager 
to  have  the  necessary  understanding. 

There  is  also  a  need  to  familiarize  all  system  program  management  functional  per¬ 
sonnel  with  the  philosophy  of  CM.  (For  that  matter,  there  is  a  need  to  familiarize  all 
program  management  personnel  with  all  the  functional  management  philosophies.)  This 
will  help  dispel  their  misconceptions  about  the  effects  of  CM  on,  and  the  role  of  the 
configuration  manager  in,  their  day-lo-day  activities. 

Also,  since  the  tracking  of  the  actual  configuration  of  operational  units  requires 
the  input  of  information  from  operational  maintenance  personnel,  there  is  a  need  to 
address  the  reasons  for,  and  effects  of,  CM  and  configuration  control  in  the  various 
maintenance  training  courses  they  attend.  We  need  to  instill,  in  the  maintenance  person¬ 
nel,  an  appreciation  of  what  increased  configuration  (proliferation)  control  can  do  to 
decrease  or  simplify  their  workload.  Otherwise,  we  will  continue  to  experience  control 
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problems,  and  information  inaccuracies,  at  the  operational  level. 

WHY  WORRY  ABOUT  CONFIGURATION  MANAGEMENT? 

As  mentioned  earlier,  the  ultimate  intent  of  configuration  management  is  to  facili¬ 
tate  and  simplify  the  logistics  support  of  your  system.  I  can’t  guarantee  that  you’ll  have 
no  logistics  support  problems  if  you  have  good  configuration  management  on  your  pro¬ 
gram.  You’ll  minimize  them,  certainly,  but  there’s  no  way  that  anyone  can  totally 
prevent  logistics  support  problems.  However,  if  you  have  poor  configuration  management 
on  your  program,  I  can  absolutely  guarantee  you  that  you’ll  have  many  logistics  support 
problems.  Configuration  management  requires  money  and  manpower  to  accomplish,  and 
time  (delays)  are  usually  required  to  accomplish  the  necessary  reviews,  whether  we’re 
checking  a  draft  specification  or  an  engineering  change  proposal.  But  configuration 
management  is  based  on  good  management  practices,  so  the  effort  is  necessary  and  cost, 
effective. 

It  comes  right  down  to  that  old  adage,  You  can  pay  me  now,  or  you  can  pay  me 
later.  You’re  going  to  have  to  pay  now  to  implement  effective  configuration  management 
on  your  program,  or  you  re  going  to  pay  later  for  lack  of  configuration  management,  and 
you’ll  probably  pay  many  times  more,  then.  It  just  makes  good  sense  to  follow  your 
common  sense  management  instincts,  to  implement  effective  configuration  management 
practices  right  from  the  start  on  your  program,  and  thus  to  avoid  the  logistics  support 
and  inventory  management  nightmares  that  have  often  resulted  from  poor  configuration 
management  on  past  programs. 

If  we  are  to  have  good  CM  on  our  programs  in  the  future,  we  need  to  take  the 
actions  now  which  will  preserve  and  improve  our  resources  of  CM  expertise  and  our  prac¬ 
tice  of  CM  throughout  the  program  life  cycle. 
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TWO  FACETS  OF  CONFIGURATION 

PHYSICAL 

-  DRAWINGS 

-  PARTS  LISTS 

-  SOFTWARE  LISTINGS 

FUNCTIONAL 

-  LOGISTICS  CONSTRAINTS 

-  INTERFACE  REQUIREMENTS 

-  PERFORMANCE  REQUIREMENTS 
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CONFIGURATION  MANAGEMENT 

ENGINEERING  NflNRGEIIENT  PRACTICES 

IDENTIFICRTION=DOCUMENTRTIQN 

-PERFORMANCE  REQUIREMENTS 
-OPERATIONAL  DESIGN 

nUDITS= VERIFICATION 

-PERFORMANCE  MET 
-DESIGN  DOCUMENTED 

CONTROL  COMMUNICATION 

-SYSTEM  ENGINEER  ALL  CHANGES 
-COMPLETE  IMPACT  DESCRIBED 

ACCOUNT  I NG  =  TRACEABILITY 

-DOCUMENTATION  -  ISSUE  THRU  CURRENT 
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CONFIGURATION  ITEMS  <CIs ) 


CONFIGURATION  IDENTIFICATION 

CUSTOMER  NEEDS  DEFINED 
ENGRG  GENERATES  DOCUMENTATION 
GOVT  PROGRESSIVELY  CONTROLS 
-FUNCTIONAL  -  SYSTEM  RQTS 
-ALLOCATED  -  Cl  RQTS 
-PRODUCT  -  Cl  DESIGN 

BASELINE  < -  HOMEWORK 

-READY  FOR  NEXT  PHASE 
-CONGRESS I ONALLY  DIRECTED 
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DESIGN  REVIEWS 

REVIEW  EVOLVING  DESIGN 
PERFORMANCE  ROTS  IN  8PEC8 

-SYSTEM  REQUIREMENTS  REVIEW  <8SR> 

-SYSTEM  DESIGN  REVIEW  (SOR> 

-SOFTWARE  SPECIFICATION  REVIEW  <SS*> 
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-PRELIMINARY  0E8IGN  REVIEW  <POR> 
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STATUS  ACCOUNTING  POLICY 

IDENTIFY  DOCUMENTS  RND  ITEMS 

-BASELINES  (SPECS,  DRAWINGS,  LISTINGS) 
-IDENTIFICATION  NUMBERS,  SERIAL  NUMBERS 

IDENTIFY  CONTRACT  INFORMATION 

-CONTRACT  NO.,  CONTRACTOR'S  FSCM 

TRACK  PROPOSAL  PROCSSING 

-MANAGE  PROCESSING  EVENTS 

TRACK  APPROVED  CHANGES 

-RECORD  OF  CHANGE  EFFECT  I V I T I ES 
-IMPLEMENTATION  STATUS 

TRACK  OPERATIONAL  CONFIGURATION 

-MAINTENANCE,  RETROFIT/MODIFICATION 

0  CONFIGURATION 
SOLUTIONS 


STATUS  ACCOUNTING  POLICY 
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MANAGEMENT  INFORMATION  SYSTEM 
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CONFIGURATION  NRNRGEilENT 

ENGINEERING  MANAGEMENT  PRACTICES 
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-PERFORMANCE  REQUIREMENTS 
-OPERATIONAL  DESIGN 

RUDITS=VERIFICRTION 

-PERFORMANCE  MET 
-DESIGN  DOCUMENTED 

CONTROL=COMMUNICRTION 

-SYSTEM  ENGINEER  ALL  CHANGES 
-COMPLETE  IMPACT  DESCRIBED 
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LESSON  12 


LESSON  TITLE:  Data  Management 
TIME:  1  hr 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  basic  vocabulary  of  data  management  and  the  process  for  identifying 
contract  data  requirements. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Define  the  following  terms: 

(1)  Data 

(2)  Data  Item  Description  {DID) 

(3)  Standard  Data  Item  Description 

(4)  Onetime  Data  Item  Description 

(5)  Acquisition  Management  System  and  Data  Requirements  Control  List 
{AMSDL) 

(6)  Contract  Data  Requirements  List  ( CDRL ). 

b.  Describe  the  Data  Call  and  Data  Requirements  Review  Board  {DRUB) 
process  which  is  used  to  identify  the  data  requirements  for  a  specific 
contract. 

c.  Describe  the  role  of  the  Data  Management  Officer  both  in  identifying 
data  requirements  and  in  managing  the  delivery  of  data  once  it  is  placed 
on  contract. 

TOPIC  INTRODUCTION: 

Now  that  we  have  addressed  how  we  (1)  analyze  each  technological  alternative  or 
weapon  system,  (2)  plan  for  supporting  these  alternatives,  and  (3)  track  these  technologi¬ 
cal  characteristics  and  changes  to  the  critical  items  in  the  weapon  system,  it  is  easy  to 
see  why  a  program  manager’s  job  is  never  done  —  there  is  so  much  information  to  sift 
through  before  a  decision  can  be  made.  There  are  many  documents  that  are  generated 
that  contain  information  necessary  to  the  government  in  monitoring  the  status  of  a  pro¬ 
gram.  This  data  is  managed  according  to  policy  identified  in  Department  of  Defense 
Instruction  5010.12.  The  Management  of  Technical  Data,  Without  a  comprehensive  data 
management  system,  there  would  be  inefficiencies  in  the  acquisition  system,  with 
ntumoossaiy  duplication,  insufficient  types,  and  untimely  receipt  of  data  submissions. 
This  lesson  introduces  the  basic  terminology  used  in  data  management,  and  the  tools 
available  to  get  data  on  contract,  so  that  procurement  of  data  is  managed  efficiently  and 
effectively.  Also,  some  of  the  data  activities  that  typically  occur  in  the  system  program 
office  are  addressed,  in  tailoring  the  data  requirements  to  your  program. 


METHOD  OF  INSTRUCTION:  Lecture/Discussion 
INSTRUCTIONAL  MATERIALS: 
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a.  Article:  An  Overview  of  Data  Management,  by  Mr  Sam  Epstein, 

AFIT/LSY 

b.  Article:  Reducing  the  Cost  of  Data  Acquisition,  by  Mr  Beck,  1  rogram 
Manager,  Jan/Feb  1985 

c.  Data  Management  videotape 

d.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 

REFERENCES: 

a.  DODI  5010.12,  Management  of  Technical  Data 

b.  DOD  5010. 12-L,  Acquisition  Management  Systems  and  Data  Requirements 
Control  List  (AMSDL) 

c.  DOD  STD-963,  Data  Item  Descriptions  (DID)  Preparation  of 

d.  AFR  310-1,  Management  of  Contractor  Data 

e.  AFSCR  310-1,  Management  of  Contractor  Data 

f.  AFLCR  310-1,  Management  of  Contractor  Data 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  An  Overview  of  Data  Management 

b.  Read  article:  Reducing  the  Cost  of  Data  Acquisition 

c.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

A  brand  new  Program  Manager  ( PM)  for  a  non-major  program  is  in  the  middle  of 
leading  his  very  inexperienced  technical  team  in  writing  a  Statement  of  Work  (SOW). 
The  following  conditions  are  given: 

a.  All  technical  members  are  unfamiliar  with  sound  data  management  princi¬ 
ples  for  identifying  and  ordering  contractually  acquired,  weapon  system  acquisi¬ 
tion  data.  (They  have  not  yet  had  SYS  100,  nor  are  they  expected  to  be  Data 
Managers). 

b.  They  have  just  been  informed  by  the  Contracting  Officer  that  much  of  the 
information  (i.e.  data)  they  need  from  the  contractor  for  their  management  and 
oversight  of  the  contract  must  be  ordered  formally  and  handled  contractually 
via  a  DD  Form  1423,  Contract  Data  Requirements  List  (CDRL).  This  data  is 
primarily  related  to  various  SOW  tasks. 

c.  They  have  been  told  there  is  a  person  called  a  Data  Manager  (DM),  with 
whom  they  must  deal,  in  getting  out  a  Data  Call  Letter  and  in  running  a  Data 
Requirements  Review  Board  ( DRRB ).  The  outcome  of  this  DRRB  will  be  the 
CDRL  for  the  Request  for  Proposal  ( RFP ). 


1.  List  some  major  planning  actions  you  would  provide  the  PM  to  help  him 
efficiently  do  his  mission  of  writing  SOW  tasks  which  might  be  linked  for  formal  Data 
Deliverables. 


2.  Discuss  how  you  would  structure  the  Data  Call  Letter  and  who  you  would 
recommend  to  chair  the  DRRB? 

Consider  best  utilization  of  the  Data  Manager  who  has  access  to  such  DM  tools  as 
the  Acquisition  Management  Systems  and  Data  Requirements  Control  List  ( AMSDL ), 
Data  Item  Descriptions  ( DIDs ),  and  AFR  310-1,  Management  of  Contractor  Data ,  which 
explains  how  to  complete  a  DD  Form  1423,  CDRL. 

BOTTOM  LINE:  The  Program  Manager  can  chair  the  DRRB  or  delegate  this  to  the 
Data  Manager.  What  would  you  do?  In  all  cases  the  Data  Manager  should  do  the  Data 
Call  Letter. 


3.  Describe  how  the  Data  Management  Officer  ( DMO )  identifies  data  requirements 
in  managing  the  delivery  of  data? 


[Acronyms  introduced  in  this  lesson,  and  their  description] 
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AMSDL  Acquisition  Management  Systems  &  Data  Requirements 

Control  List 

DAL  Data  Accession  List 

DDMO  Defense  Data  Management  Office 

DIDs  Data  Item  Description! s) 

DMO  Data  Management  Officer 

Drrb  Data  Requirements  Review  Board 

EDMO  Engineering  Data  Management  Officer 
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AN  OVERVIEW  OF  DATA  MANAGEMENT 
SECTION  I  -  INTRODUCTION 

Data  is  defined  (by  AFR  310-1)  as  recorded  information ,  regardless  of  form  or 
characteristic.  It  includes  all  the  administrative,  management,  financial,  scientific, 
engineering,  and  logistics  information  and  documentation  which  is  required  for  delivery 
from  the  contractors.  It  can  be  thought  of  as  being  either  technical  or  nontechnical  in 
nature.  DOD  Standard  963,  Preparation  of  DIDs  distinguishes  technical  data  as  Type  I 
and  nontechnical  data  as  Type  II.  Type  III  data  is  one-time  use  data  and  can  be  either 
technical  or  nontechnical.  The  overall  guidance  for  data  is  found  in  DODD  5010.12  and 
DOD  5010.12-M.  Data  is  acquired  for  two  primary  purposes: 

(1)  information  feedback  from  the  contractor  for  program  management., 
control,  and  decision  making;  and 

(2)  information  needed  to  manage,  operate  and  support  the  system,  such  as 
specifications,  technical  manuals  and  engineering  drawings. 

Data  management  is  the  function  that  governs  and  controls  the  selection,  gen¬ 
eration,  preparation,  acquisition,  and  use  of  data  from  contractors.  The  rest  of  this 
paper  will  address  the  general  terminology  used  in  data  management,  the  process  used  to 
identify  data  requirements,  and  some  selected  topics  related  to  data  management. 

SECTION  II  -  TERMINOLOGY 

Acquisition  Management  Systems  and  Data  Requirements  Control  List 

(AMSDL,  DOD  5010.I2-L)  --  An  index  which  identifies  acquisition  management  systems, 
source  documents,  and  Data  Item  Descriptions  (DIDs)  which  have  application.  A  Defense 
Data  Management  Office  (DDMO)  controls  the  AMSDL  and  the  processing  for  approval 
of  data  item  descriptions  included  in  it.  DDMO  must  process  requests  for  new  standard 
data  items  to  the  Office  of  Management  and  Budget  ( OMB ).  An  approved  data  item  is 
given  an  OMB  control  number,  with  an  expiration  date,  as  required  by  the  Paperwork 
Reduction  Act  (Public  Law  96-511). 

Data  Item  Description  (DID).  A  completed  form  (DD  Form  1664)  that  defines 
the  data  content,  preparation  instructions,  format  and  intended  use  and  recommended 
distribution  of  data  that  might  be  required  of  a  contractor.  The  DID  might  be  viewed  as 
a  specification  for  data  to  be  generated  and  delivered  as  a  result  of  a  DOD  contract. 
There  are  three  types  of  data  item  descriptions: 

(1)  Standard  data  item  description.  A  data  item  that  has  been  approved  for 
general  use,  listed  in  the  AMSDL,  and  published  and  distributed  to  the  military 
services,  federal  agencies,  and  to  subscribing  DOD  contractors  by  the  Naval 
Publications  and  Forms  Center  in  Philadelphia,  Pennsylvania. 

(2)  Tailored  data  item  description.  A  standard  data  item  that  exceeds  the 
requirement  for  information  and  must  be  tailored  downward,  or  diminished,  to 
meet  the  specific  requirement.  Tailoring  may  only  be  accomplished  to: 

(a)  clarify  or  adjust  content  to  meet  program  data  requirements  within 
the  intent  and  scope  of  the  DID. 

(b)  accept  contractor’s  format. 
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(c)  reduce  the  scope  through  deletion  of  words,  paragraphs,  or  sections. 

(3)  One-time  data  item  description.  A  data  item  that  is  developed  when  a 
data  requirement  cannot  be  met  by  use  of,  or  by  tailoring  of,  a  standard  data 
item,  or  by  combining  submittals  of  multiple  tailored  standard  data  items.  A 
one-time  DID  will  have  a  six  month  timeframe  to  be  put  on  a  contract.  Once 
on  contract,  it  is  valid  for  the  life  of  that  contract.  It  will  be  assigned  an  OT 
DID  number  from  an  approved  block  of  OT  numbers  which  (as  of  this  writing) 
is  typically  controlled  by  data  management  focal  points  at  product  divisions. 

NOTE:  One-time  DIDs  are  not  listed  in  the  AMSDL,  nor  are  they  printed  and  distri¬ 
buted  to  the  field.  The  contract  they  are  part  of  is  the  only  place  they  occur  and  the  DD 
Form  1664,  detailing  the  one-time  DID,  is  incorporated  in  its  entirety  into  that  particu¬ 
lar  contract. 

Because  of  the  limited  use,  a  one-time  DID  should  be  used  only  to  meet  the  needs  of  the 
contract  for  which  it  was  developed.  If  future  uses  are  anticipated,  the  one-time  DID 
should  be  forwarded,  through  data  management  channels,  to  DDMO  for  consideration  by 
OMB  for  approval  as  a  new  standard  DID. 

Contact  Data  Requirements  List  ( CDRL )  --  A  list  of  data  requirements  that  is 
authorized  for  a  specific  procurement  and  is  made  a  part  of  the  contract.  This  list  is 
comprised  of  a  series  of  DD  Forms  1423  (individual  CDRL  forms)  which  contain  the  DID 
identification  numbers  and  delivery  instructions.  The  CDRL  is  one  of  the  two  places  in 
the  contract  that  can  establish  a  requirement  for  the  contractor  to  deliver  data.  The 
other  area  is  by  specific  contract  clauses,  formerly  called  the  general  provisions  section, 
which  brings  in  Federal  Acquisition  Clauses  applicable  to  your  contract.  Both  the  CDRL 
and  the  clauses  require  OMB  Control  over  the  data  being  collected,  as  regulated  by  the 
Paperwork  Reduction  Act  (Public  Law  96-511): 

(1)  CDRL  data  may  best  be  thought  of  as  data  directly  linked  to  Statement 
Of  Work  (SO VV)  tasks  and  is  managed  by  the  Data  Management  Officer 
(DMO).  (Detailed  instructions  for  completing  the  DD  Form  1423, 

Contract  Data  Requirements  List  are  found  in  AFR  310-1). 

(2)  Data  required  by  FAR  clauses  most  often  deals  with  the  sound  business 
aspects  of  contracting  and  is  managed  by  the  Contracting  Officer. 

SECTION  m  -  THE  PROCESS 

The  Program  Manager  is  responsible  for  acquiring  the  contract  data  necessary  to 
manage  all  aspects  of  the  program/project.  A  Data  Management  Officer  (DMO)  is  usu¬ 
ally  appointed  to  assist  the  Program  Manager  in  this  task.  The  process  of  identifying 
and  acquiring  the  required  data  begins  in  the  Concept  Exploration  Phase  and  continues 
throughout  the  entire  system  life  cycle.  For  each  contract  to  be  issued  (usually  for  each 
phase  of  the  program),  the  formal  process  begins  when  the  DMO  issues  a  data  call.  This 
data  call  is  usually  a  letter  which  describes  the  planned  program  and  asks  functional 
managers  to  identify  and  justify  their  data  requirements  for  that  contract.  The  Air 
Force  uses  a  special  data  ordering  form  to  order  data,  in  responding  to  the  data  call. 
The  form  is  the  AF  Form  585,  Contractor  Data  Requirement  Substantiation,  explained  in 
AFR  310-1,  which  is  a  mirror  image  of  the  DD  Form  1423;  it  also  contains  blocks  to  jus¬ 
tify  the  need  for  the  data  ordered,  show  impact  for  not  ordering  the  data  and,  provide 
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the  name,  phone  number  and  office  symbol  of  the  individual  ordering  the  data.  The 
data  call  is  sent,  not  only  to  the  different  functional  offices  within  the  program  office  but, 
also,  to  all  participating  commands  and  agencies. 

All  of  the  functional  managers  identify  their  information  needs  on  the  AF  Form 
585  and  use  the  AMSDL  to  identify  standard  data  item  descriptions  that  may  meet  their 
requirements.  They  should  then  review  the  DIDs  to  assure  that  they  provide  the  needed 
data.  They  would  then  tailor  the  data  item  descriptions  to  eliminate  unnecessary 
requirements.  This  tailoring  process  is  not  unlike  special-ordering  a  new  car.  The  DID  is 
similar  to  the  dealer’s  catalog.  You  need  to  clarify  some  options  by  identifying  the 
specific  exterior  and  interior  colors.  In  other  cases,  you  have  redundant  options  (such  as 
tire  types  and  sizes),  and  you  identify  which  one  you  want.  In  many  cases,  there  are 
options  you  don't  want,  and  so  you  tell  the  salesperson  you  don’t  want  them.  In  this 
way,  you  arrive  at  the  car  you  want  without  paying  the  cost  of  options  that  you  don’t 
want. 

If  they  cannot  identify  a  standard  data  item  description,  or  tailor  a  standard 
data  item  description  to  meet  their  requirements,  they  would  generate  a  one-time  data 
item  description  on  a  DD  Form  1664,  usitm  'lie  guidance  in  DOD  Standard  963,  Prepara¬ 
tion  of  DIDs.  Their  requirements  are  sent  to  the  DMO,  usually  on  AF  F'orms  585.  This 
form  identifies  the  required  data  item  description,  delivery  instructions,  and  provides  the 
justification  for  the  acquisition  of  the  data  item. 

The  DMO  compiles  all  the  requirements  and  attempts  to  eliminate  redundant 
data  items.  The  next  step  is  for  the  Program  Manager  to  review  the  requirements  and 
the  associated  justification.  The  review  is  usually  done  in  a  meeting  called  a  Data 
Requirements  Review  Board  ( DRRB ).  This  board  is  normally  comprised  of  representa¬ 
tives  from  the  functional  areas  having  significant  data  requirements.  The  board  does  not 
vote;  rather,  they  recommend.  The  Chairperson  of  the  DRRB  makes  the  final  decision. 
(The  Program  Manager  may  chair  the  DRRB,  or  delegate  this  role- to  the  Data  Manage¬ 
ment  Officer).  Based  on  this  meeting,  the  Program  Manager  will  decide  which  data  items 
will  be  included  in  the  Request  for  Proposal,  going  out  for  the  contractors  to  respond  to, 
in  their  proposals. 

Some  DMOs  are  called  in  to  provide  technical  evaluations  to  the  negotiating 
team  commenting  on  the  contractor’s  proposed  data  preparation  and  pricing  effort.  The 
DMO,  in  conjunction  with  the  contracting  office,  will  then  finalize  the  desired  Contract 
Data  Requirements  List  ( CDRL ),  negotiate  it  with  the  contractor,  and  make  it  a  part  of 
the  contract. 

After  contract  award,  the  DMO  is  responsible  to  track,  for  timely  delivery,  all  of 
the  CDRL  data  on  the  contract.  If  the  contractor  is  late  on  delivery  or  if  the  data 
delivered  is  deficient  (including  having  restrictive  markings  not  authorized  by  the  con¬ 
tract),  the  DMO,  through  the  Contracting  Officer,  can  use  the  FAR  clause  entitled. 
Technical  Data  —  Withholding  of  Payment,  to  withhold  from  the  contractor  up  to  ten 
percent  of  the  contract  price  in  order  to  press  for  the  late/deficient  data.  If  the  Govern¬ 
ment  is  late  on  granting  approvals  to  the  contractor,  on  any  data  submitted  requiring 
Government  approval,  the  DMO  aids  the  Program  Manager  in  speeding  up  the  Govern¬ 
ment  approval  process,  to  reduce  Government-caused  contract  schedule  slippages. 
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SECTION  IV  -  SELECTED  TOPICS 
Deferred  types  of  data: 

(a)  Deferred  Ordering.  Thin  it*  explained  in  il««-  I 

(FAR),  Part  27,  which  deals  with  the  Acquisition  *»f  fedtwr*]  |)«u  *a<Jl 
Software.  These  types  of  data  are  expensive  to  prepare,  in  t!«e  required  fortt*,  and  wpda*- 
ing  and  maintaining  these  are  costly.  Examples  of  *urb  data  w«*uld  h*  et*gi  wiring  deal¬ 
ings,  computer  software,  and  technical  manuals.  IVfmvd  Ordering  of  (lata  <*  Mpp&rd 
contractually,  via  a  FAR  clause,  and  provides  for  the  delaying  the  ordering  <rf 
cal  data  generated  in  performing  tin*  contract  until  a  n*H'i  f»<r  *b«  data  can  ewt.a- 
blished,  and  the  data  requirements  ran  be  -prcilicalU  id^tiiifi*  !,  for  und*s  the 

contract.  The  typical  situation.  wli*r<-  deferred  ordering  would  apply.  U  an  und^ned 
design  where  one  is  "pushing  the  Mate  t.f  ih*-  art.”  The  data  ali’vh  ha*  Lorn  <MW'»'nd  L 
later  defined,  the  actual  order  for  th«  data  is  plam.1  contractually,  and  ri 

scheduled.  Then,  the  only  charges  for  this  data  should  U  f*r  the  nilMli*,  form  at  ring 
and  printing/  electronic  transmitting  and  computer  tap*  copying  The  charge*  for  all 
engineering  efforts  should  have  previously  |>wn  charged  agau>»i  «l»e  *1  <d  wort 

tasks  as  opposed  to  data  preparation  expense.  There  is  year  rwh  built  into  tb* 

FAR  Deferred  Ordering  Clause  which  sets  the  limitation  «*n  when  d«lcft*d  «*}.|raang  e*n 
occur. 

(b)  Deferred  Delivery.  This  is  also  explained  in  I  All.  and  is  applied  e.  .«tr*r«u* 

ally,  via  a  F.AR  Clause.  Deferred  delivery  refers  t<»  those  «jl nations  where  erf  lb*> 

technical  data  or  computer  software,  by  the  (Jov»riim<mt.  w.,uld  be  pfrmatuo  L*'  a4e> 
quate  storing  and  handling.  The  typical  situation,  when  deferred  delivery  would  apply: 
Government  inability  to  store/update/retrieve  data.  As  with  deferred  eeHc-ri^g.  deferred 
delivery  data  should  only  include  the  cost  to  rollect,  format,  print  of  make  a  tape. 
There  is  a  two  year  rule  built  into  the  FAR  Deferred  Delivery-  Clause  which  art*  the  limb 
tation  on  when  deferred  delivery  can  occur. 

(c)  Deferred  Requisitioning.  This  is  also  done  contractually;  however,  there  are 
no  FAR  Clauses  to  apply.  Instead,  the  Contracting  Officer  writes  special  custom 
language  in  a  clause  which  is  developed  to  describe  the  instant  contracting  situation. 
Now  the  terms,  prices,  and  delivery  schedule  can  be  established  up  front:  however.  the 
data  would  arrive  later.  There  are  no  year  rules;  however,  the  Contracting  Officer  could 
negotiate  a  timeframe,  to  fit  the  situation.  Typical  situations  where  deferred  requisition* 
ing  would  apply  include  lack  of  final  design,  hardware  undeployed.  and  CJovernment  ina¬ 
bility  in- house  to  manage  the  data.  The  advantages  of  deferred  requisitioning  are  the 
<  i.«\entmr>nt  d>*”*  not  More,  update,  or  retrieve  the  evolving  design  related  data.  The 
contractor  does  this  and  will  charge  for  this  additional  service.  (None  of  these  deferred 
data  techniques  are  without  additional  cost). 

(d)  Data  Accession  List  (DAL).  This  technique  employs  a  DID  for  the  listing  erf 
non-CDRL  data  which  evolves  over  the  life  of  the  contract.  The  contractor  will  create  a 
library  of  ail  this  non-CDRL.  The  DID  only  gets  the  list  of  what  is  in  the  library.  The 
Government  buying  office  can  order  data  deliverables  from  this  list.  There  is  tio  appro¬ 
val  of  any  item  from  the  list,  nor  is  there  any  say  on  format  or  content.  The  Govern¬ 
ment  is  charged  for  copying  costs  and  for  the  storing  and  retrieving  from  the  contractor’s 
data  library.  There  is  obviously  some  additional  cost,  to  set  up  a  DAL  mechanism  on  a 
contract,  but  it  is  another  way  to  have  access  to  practically  all  remaining  data. 
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[  Data  Wish  list ' 

Vaiioui  (fspon^i  to  (hr  data  call 
(  may  be  redundant  or  seemingly  e* 

{  cnaivt  A  review  procnt  by  a  Data 
|  Requirements  Review  Board  (re 
!  quirrd  (or  programs)  must 

wrub  the  data  wish  list  to 

ikat  vxhuh  rs  r*r<  rssary  and  cost 
dlniivr  lor  iK»  K'o^nment 
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simple  reijuest  like  a  copy  ot  an  en¬ 
gineering  dialling  seem  veiy  expen¬ 
sive  because  (he  contractor  must  eon 
vert  liorn  contractor  lorm.it  drawings 
to  govt-mini  nt  toim.it  di.iwmgs 
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Wait... I  just 
thought  of 
another  data 
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ance  and  payment  document.  Criti¬ 
cally  important  data  should  have 
careful  inspection  and  formal  accept¬ 
ance,  but  requiring  a  formal  DD  250 
on  a  routine  report  is  overkill. 

Fprmally  delivered  data  may  be 
separately  priced  with  payment  to  the 
contractor  after  each  accepted  data 
submittal,  or  may  be  priced-fn  with 
other  contract  line  items  (or  combina¬ 
tions  thereof).  Pricing  associated  data 
with  basic  contract-line  items  saves 
extra  administrative  effort  in  sepa¬ 
rately  pricing  and  paying  for  the 
data.  On  the  other  hand,  data  that 
represent  a  significant  contractor  el 
fort  may  deserve  to  be  paid  or.  deliv¬ 
ery.  Of  course,  you  don’t  want  to  pay 
tor  the  manual  now.  get  the  system 
months  later,  and  then  find  the 
manual  is  inadequate.  Likewise,  you 
don’t  want  the  system  delivered  now 
with  no  nr.tnual  until  later,  which 
leaves  you  with  no  choice  but  (sole 
source)  contractor  maintenance. 
Careful  management  is  necessary,  in 
coordination  with  maintenance  train¬ 
ing  and  other  logistics-support  peo-  i 
pie  to  ensure  that  necessary  data  are  ! 
^available  at  the  right  time.  | 

Delivering  Data 

When  should  data  be  delivered? 

T our  c < intuiting  officer  can  provide 
p»»nr  flexibility  on  data*delivery 
dates  lo  help  get  the  latest  and  best  l 
data  when  needed  Delivery  can  be  s 
tied  to  contractual  events:  i  e.. 
manual*  for  maintenance  60  days  be-  ! 
lot*  v  heduled  government  testing  (lo 
permit  government  training  time  that 
may  need  its  own  contract) 

By  uwng  a  ’deferred  delivery” 
clause  the  contract  can  call  for  cer¬ 
tain  data  items  to  be  delivered  within  | 
a  set  time  after  notice  from  the  con-  , 
trading  officer  This  technique  has  | 
been  useful  for  items  such  as 
engineering  drawings,  for  which  you  | 
want  to  wait  to  get  the  latest  possible  i 
version  Mi  rase  there  ate  changes.  j 

Where  more  data  may  be  desired  j 
later  but  you  don’t  know  exactly  | 
how  much  or  svhat  they  should  cost 
(pet  haps  items  are  not  yet  designed 
when  the  contract  is  priced),  a  de¬ 
ferred-ordering  clause  can  list  data 
Hems  for  later  ordering  (pricing /ne¬ 
gotiating).  Liter  in  the  program  when 
specific  requirements  are  known, 
those  gems  may  be  ordered.  This 
technique  can  be  used  for  buying  j 
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'rocurement  data.  Early  in  a  pro- 
m,  you  would  not  want  to  buy  all 
.  .ssible  drawings  if  only  a  few  were 
needed  for  reprocurement  purposes. 
The  deferred-ordering  clause  permits 
later  identification  of  exactly  whi^h 
parts  are  identified  for  reprocure¬ 
ment,  and  then  permits  buying  draw¬ 
ings  for  those  items.  Buying  repro¬ 
curement  data  this  way  can  be  a  dif¬ 
ficult  sole-source  negotiation.  One 
cost  and  administrative  effort  solu¬ 
tion  to  prevent  later  difficult  negotia¬ 
tions  is  to  consider  prepricing  a  fixed 
price  for  each  size  reprocurement 
drawing.  Thus,  each  "A"  size  (regular 
page)  drawing  would  be  a  certain 
price,  and  so  on  up  for  drawings 
.  through  the  large  "E"  drawing,  which 
would  be  more  expensive.  Then, 
when  it  is  time  to  order  reprocure¬ 
ment  drawings,  the  pricing  would 
consist  of  extending  the  prices  per  size 
by  the  number  of  drawings  of  that 
size. 

Getting  the  right  data  requirements 
|  on  contract  require  management's  at- 
lention.  A  good  data  manager  can 
'•elp  save  costs  and  help  a  program 
n  smoother  by  putting  an  aggres- 
>r  effort  on  data  review,  tailoring 
,  requirements,  and  ensuring  accurate 
j  preparation  of  the  CURL,  and  any 
:  special  contract  requirements. 

i 

I  Reducing  Data  Cost 

I  I  lie  tirvt  and  best  place  to  trv  to  get 
I  a  handle  on  data  costs  is  at  the  data 
I  <  all.  1  he  tone  of  the  call  letter  or  com¬ 
munication  will  tell  people  whether  to 
open  their  ANISIM  (DOD  50tXi  \o\  \ 
and  order  all  data  items  in  their  tield 
like  a  shopper  with  a  free  rrcdil  i  arcl. 
or  whether  to  consider  carefully  cxa<  t 
ly  what  data  are  needed  and  why 
Responses  to  the  data  call  may  reveal 
redundancy  where  several  users  c  ould 
agree  to  use  the  information  from  one 
report  rather  than  different  reports 
looking  at  the  DID  preparation 
instrurtion*  may  reveal  numerous  op 
portunities  to  cut  out  unnecessary 
detail  or  entourage  alternative  con¬ 
tractor  lormat  data  so  that  the  contrac  - 
^  lor  doesn't  have  to  reprogram  its  com 
,  polrr.  or  change  its  internal  procedure 
nisi  to  transmit  data  in  government 
***!  format 

Ri  ten-U.es  on  the  DID  are  piovid 
rd  to  oilier  applicable  MIISI’H  S  or 
SIDS  Often,  several  documents  will 
reler  also  to  other  references  this  is 


culled  tiering"  uiul  may  be  very  cost¬ 
ly  if  requirements  ..re  not  tailored. 

in  Idiiuary  198-5  the  Deputy  Sec 
retury  ('I  Detense  designated 
OllSDREfAMlII’as  the  local  point  for 
a  lest  program  to  eliminate  non-cost - 
effective  contrac t  requirements.  Under 
this  DOD  initiative,  the  services 
selected  inaior  programs  to  review  ag¬ 
gressively  and  reduce  unnecessary  data 
and  specification  requirements.  Policy 
is  thus  changing  on  data  requirements 
toward  justifying  inclusion,  rather 
than  ordering  whenever  in  doubt.  To 
communicate  the  new  policy  and  pro¬ 
vide  useful  "how  to"  hints  and  guid¬ 
ance  lor  limiting  data  requirements, 
DOD  lid-  dialled  a  handbook  (24813 / 
for  program  managment  use. 


This  data 
is  so  new  the 
ink's  not  even 
dry  / 


There  are  difficult  judgment  areas 
regarding  how  much  data  to  order  at 
th^  start  of  a  program.  We  need  to 
consider  and  tailor  requirements  care¬ 
fully  to  specific  needs,  using  func¬ 
tional  requirements  and  contractor- 
format  data  where  applicable.  With 
more  communication  about  the  prob¬ 
lem,  and  less  how  to,  we  release  the 
creative  ingenuity  of  industry  un¬ 
hampered  by  unnecessary  require¬ 
ments. 


Do  We  Need  Data  For  Competi¬ 
tive  Reprocurement? 

Some  people  argue  that  DOD 
should  acquire  all  data  that  might  be 
needed  for  possible  maintenance  sup¬ 
port.  Some  general  contract  language 
is  set  up  to  do  this.  Contractors  are 
asked  to  propose  prices  that  cover  all 
data  needed  for  operation  and  main¬ 
tenance  of  the  system.  Thus,'  the  price 
offered  to  the  government  will  nor¬ 
mally  include  the  price  of  unlimited 
data  rights  to  permit  operation  and 
maintenance.  Nobody  knows  the  cost 
of  this  policy.  Many  assume  savings 
of  future  competition  may  repay  the 
initial  acquisition  expense  of  proprie¬ 
tary  data,  but  this  is  not  necessarily 
so. 

Let's  assume  you  are  buying  a  (low- 
volume)  system  that  uses  a  commer¬ 
cial,  high  technology  state-of-the-art 
component  like  a  new  computer.  In 
simple  terms,  let's  assume  you  are 
buying  a  vehicle— a  small  truck  that 
will  be  modified  to  carry  a  military 
item.  Assume  the  manufacturer  has  a 
“black  box"  computer  managing  the 
engine  spark,  fuel  injection,  and  other 
functions.  If  this  proprietary  technol¬ 
ogy  is  a  key  to  its  competitive  busi¬ 
ness.  would  the  contractor  even  offer 
its  latest  technology  system  to  DOD 
il  we  insisted  on  unlimited  data 
rights?  Perhaps  not!  Perhaps  we 
would  get  a  less-reliable  old  carburet¬ 
or  if  we  insisted  on  data.  Or,  perhaps, 
our  $5,000  basic  chassis  and  engine 
would  be  offered  at  $5  million,  which 
might  be  a  fair  and  competitive  price 
for  the  technological  secret. 

What  does  this  moan7  (Vo  need  con l- 
inon  s cnee  in  our  dntn  acquisition 
I’ohcu  Wc  need  to  consider  cost  ver¬ 
sus  benefit  to  make  intelligent  decisions 
about  what  data  we  really  need.  If  a 
limited-quantity  system  has  one  pro¬ 
prietary  IBM  computer,  it  might  be 
cost-effective  to  hire  IBM  for  repair 
levond  the  capability  of  the  military 
technicians  (if  even  necessary),  rather 
than  to  consider  buying  the  proprie¬ 
tary  data  to  allow  competing  the  com¬ 
puter  maintenance  to  another  firm. 

Predetermination  of  Rights 

It  is  far  better  to  resolve  who  will 
own  rights  to  data  before  contracts 
are  awarded  than  it  is  to  argue  later. 
The  contracting  officer  can  insert  a 
clause  in  the  request  for  proposals, 
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which  essentially  says  the  govern¬ 
ment  will  receive  unlimited  rights  in 
all  but  certain  areas.  Then,  the  con¬ 
tractor's  response  simply  lists  areas 
that  it  feels  are  proprietary;  this 
becomes  a  basis  for  negotiated  agree¬ 
ment  in  the  contract  to  specify  what 
(if  any)  data  may  be  delivered  with 
less-than-unlimited  rights.  Clarifying 
data  rights  before  award  by  predeter¬ 
mination  can  preclude  later  prob¬ 
lems. 

Data  Management 

After  contract  award,  data  begin  to 
flow  in  as  required  by  the  CDRL 
Careful  planning  before  award,  and 
management  alter  award  can  ensure 
data  are  received  as  needed  and  when 
needed.  In  addition  to  the  special 
techniques  ior  deferred  delivery 
deferred  ordering,  or  milestones 
related  delivery,  data  managers 
should  establish  a  solid  management 
suspense  system  to  ensure  data  are 
received  on  time,  and  that  any  neces¬ 
sary  action  is  complete. 

Simple  receipt  of  a  data  package 
does  not  mean  it  is  adequate.  Time 
must  be  alloted  for  reviev ,  govern¬ 
ment  comments  if  necessary  and 
possible  resub. mssion  with  correc¬ 
tions.  Where  instructions  are  vague, 
o'-  a  contractor  has  less  >han  top- 
|  quality  people  preparing  data,  ti  e 
j  government  data  manager  can  antici¬ 
pate  need  for  corrections  and  resub¬ 
missions.  Sometimes,  government 
reviewers  are  too  critical  and  the  con¬ 
tractor  expects  its  first  submissions  to 
be  routinely  rejected  with  lengthy 
comments.  This  can  degenerate  into  a 
game  where  the  contractor  puts 
minima!  effort  into  initial  submis¬ 
sions  and  letters  so  that  the  govern¬ 
ment  reviewer  must  be  the  proof¬ 
reader  and  editor.  This  wastes  time 
and  money,  so  the  program  manager 
will  want  to  take  preventive  action. 

Getting  Good 
First  Submission 

Government  management's  interest 
and  contractor  management's  interest 
determine  the  quality  and  timeliness 
of  data  submissions.  Where  no  one 
cares  or  mentions  data  requirements, 
you  may  expect  less  effort  and,  per¬ 
haps,  poorly  prepared  or  late  work. 
Contractor  interest  is  the  secret  for 
getting  good  data  on  time.  This  inter¬ 
est  may  be  automatic  due  to  company 
pride  or  a  sense  of  responsibility.  But, 
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Data  checklist 

□  Data  strategy  discussions 
!  (  Data  call  emphasizing  strategy 
1 1  Data  review: 

|  i  max  tailoring 
|  L  eliminate  redundancy 
[  i  to  allow  contractor  format 
when  possible 

;  Draff  CDRL 

Draft  SOW  to  match  CDRURevlew  SOW 
i  for  cross-referencing  to  CDRL 

;  Consider  data-rights  nnsstlons 

Draft  RFP  wlih  SOW,  CDRL,  and  special 
retirements  for  Industry 

i  i  'Use  predetermination  clause  as  appropriate 
Review  Industry  feedback  on  data  cost  drivers 
j  '  J  Tailor  final  requirements  to  Hmlt  tiering 
Cscrrilnstc  Rn?l  data  requirements 
induce  data  In  award-fee  plan.  If  appropriate 
1  Drslgrrls  data  management  responsibilities  and 
approach  for  post-award  monitoring 

■SfcSSS 


it  can  he  stimulated  before  the  due 
date  vir  monthly  review  or  follow-up 
questions  by  the  government  pro- 
gr.ua  manager.  Quality  of  data  sub¬ 
missions  is  a  subjective  area  that  may 
he  effectively  improved  by  an  award- 
fee  provision 


Timely  Response  to 
Data  Submissions 

If  comments  need  to  be  made  to 
data  submissions,  consider  and 
establish  reasonable  times  for  action. 
jMany  contracts  require  contractor  re¬ 
sponse  to  government  comments 
within  a  number  of  days  (30,  45,  60) 
for  resubmission;  therefore,  similar 
time  limits  should  be  placed  on  gov¬ 
ernment  personnel  for  government 
action.  It  is  interesting  to  see  the  im¬ 
pact  on  the  government  bureaucracy 
if  your  contractor  has  a  clause  saying 
"lack  of  response  by  the  government 


within  45  days  shall  be  deemed  gov-  j 
ernment  approval." 

The  Bottom-Line  j 

Mow  we  approach  data  acquisition  | 
drives  overall  program  costs  and  ! 
potential  success.  Basic  information  ! 
above  provides  a  general  framework  | 
of  considerations  for  management  ! 
improvement.  I 

The  data  checklist  (Chart  1)  shows 
only  big-picture  reminders,  each  of 
which  needs  careful  consideration, 
sound  planning,  and  aggressive  im¬ 
plementation  to  gain  success.  The 
bottom-line  is  reduced  data  cost  while 
still  obtaining  essential  information. 
Exactly  how  much  data  are  essential 
is  the  subjective  management  judg¬ 
ment  of  which  is  worth  buying. 

The  fiscal  imperative  must  become 
"order  only  if  absolutely  needed" 
rather  than  "order  in  case  someone 
might  need  it.”B 

january-February  1985 
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SAM  EPSTEIN 
AFIT/LSY 
JUNE  1987 
A/V  785-3355 


DEFENSE  DATA  MANAGEMENT 
LESSON  OUTLINE 


DATA  MANAGEMENT  PROGRAM:  OBJECTIVES,  ENFORCEMENT,  DEFINITIONS, 

DOD,  USAF  DATA  MGMT  ORGANIZATION 

IMPACT  OF  PAPERWORK  REDUCTION  ACT:  TIGHTER  RULES  ON  COLLECTING 

DATA 

IMPACT  OF  1984  DEFENSE  AUTHORIZATION  ACT:  CONTROLLED  DISTRIBUTION 

OF  TECHNICAL  DATA 

DATA  MANAGER  S  TOOLS  OF  THE  TRADE:  AMSDL,  DISs,  CONTRACT  FORMS 

FLOW  PROCESS  OF  IDENTIFYING  DATA:  DATA  CALL,  DATA  REQUIREMENTS 

REVIEW  BOARD 


PROGRAM  ENFORCEMENT 


DATA  DEFINED  AS  *  *  *  RECORDED  INFORMA  TION , 

REGARDLESS  OF  FORM  OR  CHARACTERISTICS. 

*  CONTRACTORS  CONTRACTUALLY  REQUIRED  TO  DELIVER  DATA: 
UNDER  GUIDELINES  OF  PAPERWORK  REDUCTION  ACT 

**  SOW  LINKED  DATA:  VIA  DATA  ITEMS  (DIDs) 

LISTED  ON  DD  FORM  1423,  CONTRACT  DATA  REQUIREMENTS 
LIST  (CDRL) 

**  CONTRACT  FAR  CLAUSE  DATA  (NO  DIDS) 
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DATA  MANAGEMENT  PROGRAM  OBJECTIVES 


*  ACQUIRE:  MINIMUM  ESSENTIAL  DATA 
♦ASSURE  DATA  ITEMS  ARE  SELECTED  FROM  THE  AMSDL 

OR 

AUTHORIZED  AS  ONE-TIME  DATA 

*  ACQUIRE  DATA  IN  CONTRACTOR  FORMAT,  WHEN  PRACTICAL 

*  ASSESS  DATA  CONTINUALLY  THROUGHOUT  PROGRAM  LIFE 


REORGANIZATION  OF  DATA  MANAGEMENT  WITHIN  DOD 

EFFECTIVE  23  MAR  86 


OASD  (AAL)  SDM 

STANDARDIZATION  A  DATA  MANAGEMENT  OFFICE* 


DSPO 

DDMO 

DPSO 

DEFENSE  STANDARDIZATION 

DEFENSE  DATA 

DEFENSE  PRODUCT 

PROGRAM  OFFICE 

MANAGEMENT  OFFICE 

STANDARDS  OFFICE 

*  FORMERLY:  DMSSO  DEFENSE 
MATERIEL  SPECIFICATIONS  \ 
STANDARDS  OFFICE 
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US  AIR  FORCE  DATA  MANAGEMENT 

HQ  USAF/RDXM  HQ  IJSAF/LEYE 

HQ  AFSC/SD  HQ  AFALC/SE 

PRODUCT  DIVISIONS  AIR  LOGISTICS  CENTERS 

PAPERWORK  REDUCTION  ACT  OF  1980 

PUBLIC  LAW  9(5-511 

*  IMPACT  OF  PL  96-511  ON  CONTRACTOR  DATA  SUBMITTALS 

**  ONLY  AUTHORIZED  DATA  AS  PUBLISHED  IN  THE  AM3DL  OR  THE 
FAR  IS  LEGALLY  REQUIRED  TO  BE  FORMALLY  SUBMITTED  TO  THE 
GOVERNMENT 

**  ANOTHER  MECHANISM  OF  AUTHORIZED  DATA  IS  A  ONE-TIME  DID 
PUBLISHED  IN  ONE  DOD  CONTRACT  FOR  USE  ONLY  IN  THAT  CONTRACT 
WHICH  HAS  BEEN  ASSIGNED  AN  OMB  CONTROL  NUMBER 

**  AUTHORIZED  DATA  MEANS  THE  DATA  REQUEST  DOCUMENT 

AS  WRITTEN 

OR 

AS  TAILORED  DOWN 
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SUMMARY:  IMPACT  OF  PL  96-511 


NOW  BY  LAW:  CONTRACTORS  ARE  NOT  REQUIRED  TO  PROVIDE 
ANY  CDRL  DATA  AS  A  FORMAL  SUBMITTAL  WHICH  IS 
ILLEGALLY  TAILORED 
i.e.,  it  is  really  requesting  information  which  is 


ABOVE  &  BEYOND 

THE  PUBLISHED,  OFFICIAL  DATA  ITEM  DESCRIPTION 


MAJOR  CULPRIT:  IMPROPER  TAILORING  (i.e.,  UPWARD)  IN  THE  REMARKS 
BLOCK  OF  THE  CDRL  WHICH  CALLS  OUT  THE  DID 


THE  NE  W  NATIONAL  ASSET:  AMERICAN  UNCLASSIFIED  TECHNICAL 
INFORMATION  HAVING  MILITARY  OR  SPACE  APPLICATION 


INCREASED  PROTECTION  PROVIDED  BY  THE  1984  DEFENSE 
AUTHORIZATION  ACT  AND 


DODD  5230.24  Distribution  Statements  on  Technical  Documents 

DODD  5230.25  Withholding  of  Unclassified  Technical  Data  from  Public 
Disclosure 
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IMPLEMENTED  IN  CONTRACTS  BY  ORDERING  MARKING  OF  DATA  WITH 
DISTRIBUTION  STATEMENTS  WRITTEN  ON  ALL  TECHNICAL  DATA  SUBMITTED 


(BLOCKS  8  &  16,  DD  FORM  1423,  CAN  CITE  OR  REQUIRE  DETERMINATION  OK 
DISTRIBUTION  STATEMENT) 


Distribution  Statement  A: 
Distribution  Statement  B: 
Distribution  Statement  C: 

Distribution  Statement  D: 
Distribution  Statement  E: 
Distribution  Statement  F: 


Unlimited  Distribution 

LI.S.  Government  Agencies  Only 

LI.S.  Government  Agencies  and  their 
Contractors 

DOD  and  DOD  Contractors 
DOD  ONLY 

Distribution  as  directed  by  DOD  Controlling 
Office 


Distribution  Statement  X:  U.S.  Government  Agencies  and  Private 

Individual  Enterprises  eligible  to  obtain 
export  controlled  technical  data 
LAW  10  U.S.C  140c. 


DATA  MANAGER’S  TOOLS  OF  THE  TRADE 

*  AMSDL:  Acquisition  Management  Systems  and  Data  Requirements  Control 
List  (Now  the  DOD  5010.12-L)  (formerly  was  the  DOD  5000.19-L) 

Listing  of  all  approved  Standard  DIDs 

*  DID:  Data  Item  Description  (DD  Form  1664) 

Individual  Description  of  One  Collection  of  Recorded  Information 

Standard  DID:  Scientific/Technical  (TYPE  I) 
or 

Mgmt/Administrative  (TYPE  11) 


Note:  Office  of  Management  &  Budget  (OMB)  considers  a  DID  a  Rules  Document  which 
must  have  an  OMB  Control  Number  and  Expiration  Date  Signifying  if  has  been 
Approved  by  OMB  per  the  Paperwork  Reduction  Act:  PL  96-511 
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OMS  CONTROL  NO..  0704  0!!] 
EXDATE;  E/30/86 


Tzmosaoa 
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(NCIMIRING  SUPPORT  U”A  ((SO) 


3.  DISC* I PIIOH/PURPOSC 

3.1  Inqineer ing  Support  Data  ((SO)  consists  of  tot.  schematics,  assembly  drawings, 
program  listings  and  computer -generated  outputs,  functional  flow  diagrams,  test  strategy 
reports,  ami  any  relevant  information  to  provide  the  life  cycle  support  of  the  TPS, 

3.2  the  purpose  of  the  (SO  is  to  provide  all  documentation  essential  to  a  full  comprehen¬ 
sion  of  the  intent,  design,  structure  and  interrelation  of  all  elements  of  the  TPS. 


4. APPROVAL  0A1(  5.0fFIU  Of  PRIMARY  RESPONSIBILITY  (OPR)  ba.OftC  RCqUIREO  bb.GIOEP  REQUIRED 
(YYMKPO)  AS 

8701  IS 


7.  APPL  IC A 1 1Dfi/  IMURRILAI I ONSIUP 

7.1  This  Data  Item  Description  (010)  contains  the  format  and  content  preparation  instruc¬ 
tions  for  that  data  generated  by  5.4  of  MIL-STI)-2U77A(NAVY) . 

7.?  IMs  PID  is  related  to  01  -Al IS-H02II4,  lest  Program  Set  Document  (TPSl)). 

7.3  This  DID  supersedes  PI-I-2I564A,  tlu I - T -Z 1 36 1A .  DI-T-2IS53A,  and  U0I-T-2I359A. 

7.4  When  l»>th  this  DID  and  U1  -Al  lS-U0284are  cited  on  Lite  DD  form  1423,  Inis  DID  or 
OI-AllS-HO?U1must  be  tailored  in  (1  luck.  16  of  the  Oil  Form  1423  to  "ULLtrE'*  duplicate  data 
elements. 


8.  approval  l imi tai ion 


'la.  AITL  ICAIIlE  r OHMS 


9b.  AM SC  HUMBER 
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10.  PREPARATION  INSIRUCUDNS 

10.1  Source  Document .  Ihn  applicable  Issue  of  the  documents  cited  lierein,  including  their 
approval  dates  and  dates  of  any  applicable  amendments  and  revisions,  shall  be  as  reflected 
In  the  contract. 

10.2  Contents.  Engineering  Support  Data  ( E SO)  shall  consist  of  the  following  elements,  as 
required,  depending  on  the  lest  requirements  for  the  UUT,  the  capability  of  the  ATE,  and 
the  requirements  of  the  work  author  i/at  ion  document  or  contract. 


Referem  e  Documents 
lest  Strateqy  Report  (1SR) 

Test  Program  Listing 
Functional  Flow  Chart  (FTC) 
Diagnostic  Flow  (.hart  (Urc) 
fest  Diagrams  (IDMs) 

AIG  Support  Data 

Computer  Program  Aids  Documentation 
Reproducible  Copy  of  TPI  Master 
Unique  Parts  Specification 
ID  Data  Package 
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Previous  edition  is  obsolete. 


PAGE  1  OF  22  PAGES 


DATA  MANAGER'S  tOHUs 


*  CDHL  Cutinxi  N«  U****iPtm**»i»  liwi  OS)  HIM VI  ||i)| 

(  >«trw1  IW^twrM  *Imw%  *aM*  •%!  DM)* 

lx)  fillr  1*1  DID  V«e«J*rf 

•Awl 

i.ak*  Hw  HID  «*»  H»*  Mm 
Mm  null,  DID 


ll  •’<*»  (wwilirt  **  >•<«»«>  •«  iwr"!  <ju*Hy  (Wi*  OH) 

Form  3SOL  pr *w4  (Mirf  >4  L  *■•)'■«»«•  **  *« *.!.«• 

tKiW  WWHli  T\t|()fl|V«  cH  rii»  l»ll»  /T 
(AMI  3IO-I  irlK  h-  «  io  rumt^tr  «  |>D  I  *<m  1133) 


CllHS:  D** i  ||f»}<ii*'ftOf*i  »* inti  i  A)  |  0)1  \|  V*-*f 

%«»  f-tfl) 

Look  4 Mr  l«  lb*  I  Dill  «bi<li  ««t>  «ti<l  hw 

io  fw**#MMwe 

MW)  4a  yaw  arr4  tiki*  Pit)  '< 

Ht<f  ha  pa  ft  if  tkr  Off}  »*  mat  at4rt*4^ 


12*35 


SAHPL B  OP  AM  ALTONATS©  CO  PC  AN  142 1 


I TOTAL 


ONTRACTOR  DATA  r  l»*  MENT  SUBSTANTIATION 


x 

S  « 

I  d 

<  ■ 

t  o 


'll 

01 

44 

0)  r 

,  HO 
"  O.rl 
«  E  4» 

;  o  o 

Sum 


0J  • 
41  in 
id  o> 

•d  *h 

o. 
0)  o 
r.  o 

p 

01 

H4  1-4 

o  0. 


0) 

•0 

y 

01  • 

r-l 

•O  'll 

O 

•rl  Q) 

R 

>  in 

•rl 

0  y 

*— 

>1 

(1.  01 

W 

.n 

4» 

•0 

A 

n  P 

tr> 

m  - 

•rl 

1: 

l« 

>1  «i 

n.  0 

r-l 

0 

id 

0  >. 

> 

0) 

0 

m  .n 

u 

4J 

n, 

r. 

n. 

U  >1 

« 

ra  r. 

4»  U 

a 

4« 

41 

id  u 

•d 

R 

•O 

-  id 

n 

01 

M  OJ 

> 

Q  01 

id 

ll 

JC 

01  01 

E  'll 

4» 

-.1  -.1 

0 

4i  in 

R 

1  R 

0)  0 

in 

R  O 

01 

O 

O  . 

in 

•U  — 

id  n 

•R 

M 

4-1  (1 

in  a 

II  -rl 

4» 

0 

01 

in 

•rl 

HI 

ll 

4*  44 

•rl  44 

•O  Xi 
U 

•u 

id 

.n 

•O 

U  iH 

•0  id 

A  « 

44  rl 

01  *r| 

a 

0) 

0. 

r-l 

R  A 

6 

H 

01 

R  R 

n 

H  ? 

» 

A* 

S5 

H  id 

H  id 

• 

• 

• 

• 

• 

r 

H 

Ol 

n 

ft n 

ID 

sow 


LETTER 


AF585 

RESPONSES 


AF58S*S 

SCKUDOED 


<>' I  »  ,  *<»'.  W/  V~<V  j  ^  ,  ;,)  <  •  -  | 


PRAET 

CPRL 

0>»I4Z5) 


•T>ATA  RtQUlRlNKNfS 

RlVIfUl  doMpfPRRB) 

CM Alt3  final  cwacjpMj) 

•  RCQUEST  for 

PROPOML(ftFP)lFMllffij) 


winuitsmoM 
WSMinoMl 
mwj  SueMiritftS 


2-28 


LESSON  13 


LESSON  TITLE:  Manufacturing  Management 
TIME:  2  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  role  and  objectives  of  manufacturing  management  throughout  the 
system  acquisition  process. 

SAMPLES  OF  BEHAVIOR:  Each  student  will  be  able  to: 

a.  Define  manufacturing  and  discuss  the  role  of  manufacturing  management 
in  DoD  acquisition  program. 

b.  Describe  the  manufacturing  management  activities  during  the  Concept 
Exploration/Definition  phase  of  a  program. 

c.  Describe  the  manufacturing  management  activities  during  the  Concept 
Demonstration  and  Validation  phase  of  a  program. 

d.  Describe  the  manufacturing  management  activities  during  the  Full-Scale 
Development  phase  of  a  program. 

e.  Describe  the  manufacturing  management  activities  during  the  Production 
phase  of  a  program. 

f.  Describe  the  following  manufacturing  initiatives: 

(1)  Industrial  Modernization  Incentive  Program; 

(2)  Work  Measurement; 

(3)  Transition  from  Development  to  Production. 

TOPIC  INTRODUCTION: 

The  topic  of  manufacturing  management,  which  has  been  called  production 
management,  needs  to  be  understood  by  most  program  managers.  When  your  program 
starts  ramping  up  for  production,  this  is  not,  and  should  not  be,  the  first  time  you  have 
addressed  manufacturing  issues.  Manufacturing  management  is  a  process  that  can  start 
as  early  as  the  Concept  Exploration/Definition  phase  and  it  continues  throughout  the 
acquisition  life  cycle.  This  lesson  introduces  these  activities,  how  they  might  affect  your 
program,  and  three  unique  manufacturing  initiatives  your  program  may  be  experiencing 
in  the  future. 

METHOD  OF  INS  TRUCTION:  Lecture/Discussion 
INSTRUCTIONAL  MATERIALS: 

a.  Article:  Manufacturing  Management  in  the  Weapon  System  Acquisition 
Process,  by  Maj  Mike  Farr,  AFIT/LSY 

b.  Manufacturing  Management  videotapes 

c.  Lesson  viewgraphs 
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AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4*'  tape  player 
REFERENCES: 

a.  AFR  800-9,  Production  Management  in  the  Acquisition  Life  Cycle 

b.  DOD  Directive  4245.6,  Defense  Production  Management 

c.  DOD  Directive  4245.7,  Transition  from  Development  to  Production 

d.  DOD  Manufacturing  Management  Handbook  for  Program  Managers , 

Defense  Systems  Management  college,  July  1984 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Manufacturing  Management  in  the  Weapon  System 
Acquisition  Process 

b.  Scan  lesson  viewgraphs 
DISCUSSION  QUESTIONS: 

1.  What  arguments  would  you  use  to  persuade  a  program  manager  that  early  fund¬ 
ing,  during  concept  exploration/definition  and  concept  demonstration/validation,  of 
production-related  tasks  is  vital  to  the  success  of  the  program? 


2.  Discuss  the  manufacturing  activities  occurring  during  each  phase  of  the  acquisi¬ 
tion  life  cycle. 


3.  The  manufacturing  manager  for  a  major  program  has  suggested  to  the  Program 
Manager  ( PM)  that  a  feasibility  assessment  should  be  funded  during  concept 
exploration/definition  and  concept  demonstration/  validation.  The  PM  is  reluctant 
because  we’re  not  worried  about  production  yet  —  we  won’t  get  there  for  another  5  or  6 
years.  What  is  the  potential  impact  of  failure  to  fund  this  activity? 


4.  What  critical  areas  of  interest  should  be  examined  during  a  Production  Readi¬ 
ness  Review  ( PRRft 


5.  Why  do  contractors  resist  work  measurement? 


6.  What  is  the  significance  of  the  "Hidden  Factory"?  What  does  it  imply  and  what 
is  the  impact? 
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[Acronyms  introduced  in  this  lesson,  and  their  description] 


Chapter  13 


F0T4E  Follow-On  Operational  Test  and  Evaluation 

FSD  Full  Scale  Development 

GFP  Government  Furnished  Property 

1MIP  Industrial  Modernization  Incentive  Program 

PRR  Production  Readiness  Review(s) 
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MANUFACTURING  MANAGEMENT 
IN  THE 


WEAPON  SYSTEM  ACQUISITION  PROCESS 
INTRODUCTION 

The  term  manufacturing,  or  production,  has  wide-ranging  application  anytime 
scarce  resources  are  being  transformed  into  goods  and/or  services.  For  our  purposes, 
manufacturing  is  the  transformation  of  raw  materials  into  products  needed  to  perform 
the  DOD  mission  of  national  security.  The  resources  required  for  this  transformation 
process  include  people,  equipment,  money,  material,  facilities,  manufacturing  technology 
and  processes,  and  time. 

Management  of  the  manufacturing  process  is  a  subset  of  the  larger  function  of 
program  management  and  represents  the  techniques  of  economically  planning,  organiz¬ 
ing,  directing,  and  controlling  the  resources  needed  for  production.  A  primary  goal  of 
manufacturing  management  is  to  assist  program  managers  in  assuring  that  defense  con¬ 
tractors  deliver  goods  and  services,  of  specified  quality,  on  time,  and  within  agreed  cost 
constraints.  To  accomplish  this  goal,  manufacturing  managers  must  become  involved 
EARLY  in  the  acquisition  life-cycle  of  a  program. 

This  early  involvement  is  crucial  if  the  DOD  expects  acquisition  programs  to  func¬ 
tion  smoothly  during  the  production  phase,  where  the  largest  portion  of  acquisition  dol¬ 
lars  is  expended.  Early  involvement  of  the  manufacturing  function  provides  the  oppor¬ 
tunity  to  identify  and  reduce  many  of  the  major  risks  that  have  caused  so  many  DOD 
programs  to  falter  during  the  transition  from  development  to  production,  experiencing 
instead  substantial  cost  overruns,  schedule  delays,  and  performance  compromises. 

The  remainder  of  this  article  addresses,  first,  some  of  the  most  important 
manufacturing  activities  that  should  occur  during  each  phase  of  the  acquisition  process, 
and  second,  briefly  describes  several  manufacturing-related  initiatives  that  are  affecting 
the  management  of  DOD  acquisition  programs.  The  material  on  manufacturing  activi¬ 
ties  is  excerpted  from  the  DOD  Manufacturing  Management  Handbook  for  Program 
Managers ,  published  by  Defense  Systems  Management  College. 

MANUFACTURING  ACTIVITIES  DURING  THE  ACQUISITION  PROCESS 

I.  CONCEPT  EXPLORATION/DEFINITION  PHASE: 

A.  Evaluate  Production  Feasibility 

The  program  manager  should  ensure  that  a  manufacturing  feasibility  assessment 
is  accomplished  in  the  initial  phases  of  product  development.  The  feasibility  estimate 
determines  the  likelihood  that  a  system  design  concept  can  be  produced  using  existing 
manufacturing  technology  while  simultaneously  meeting  quality,  production  rate  and 
cost  requirements. 


13-4 


The  feasibility  analysis  involves  the  evaluation  of: 

1.  Producibility  of  the  potential  design  concepts. 

2.  Critical  manufacturing  processes  and  special  tooling  development 
which  will  be  required. 

3.  Test  and  demonstration  required  for  new  materials. 

4.  Alternate  design  approaches  within  the  individual  concepts. 

5.  Anticipated  manufacturing  risks  and  potential  cost  and  schedule 
impacts. 

The  feasibility  assessment  is  accomplished  to  bound  the  manufacturing  risks 
incurred  in  selecting  a  particular  design,  fabrication  concept  and  material  as  the  basis  for 
moving  into  the  demonstration  and  validation  phase.  Without  this  type  of  assessment, 
the  program  manager  may  find  that  later  phases  of  the  program  cannot  be  accomplished 
within  the  defined  thresholds  as  a  result  of  incompatibilities  between  the  system  design 
and  the  manufacturing  technology  available  to  execute  it. 

B.  Assess  Production  Risks 

Based  upon  the  feasibility  assessment,  the  program  office  should  develop  a 
manufacturing  risk  evaluation  to  quantify  the  statement  of  manufacturing  feasibility. 
Manufacturing  risk  assessment  is  a  supporting  tool  for  the  contractor  and  program  office 
decision  making  process.  It  seeks  to  estimate  the  probabilities  of  success  or  failure  associ¬ 
ated  with  the  manufacturing  alternatives  available.  These  risk  assessments  may  reflect 
alternative  manufacturing  approaches  to  a  given  design,  or  may  be  part  of  the  evaluation 
of  design  alternatives,  each  of  which  has  an  associated  manufacturing  approach.  It 
should  also  consider  the  sensitivity  of  the  feasibility  estimates  to  the  assumptions  which 
were  made  on  those  areas  of  the  design  for  which  specific  design  data  was  not  available. 

The  quantified  risk  levels  can  then  serve  as  the  basis  for  the  development  of 
specific  risk  resolution  approaches  for  the  later  phases  of  the  acquisition  cycle  and  can 
provide  guidance  to  the  budget  estimation  process.  In  programs  where  manufacturing 
risk  has  not  been  addressed  during  development  phases,  there  have  been  problems  during 
the  production  phase  involving  high  cost,  extensive  design  changes,  unplanned  material 
and  process  changes,  and  difficulties  in  delivering  hardware  on  time  which  conforms  to 
the  contract  requirements. 

C.  Identify  Manufacturing  Technology  Needs 

The  evaluation  of  manufacturing  capability  is  based  on  the  analysis  of  the  compa¬ 
tibility  of  the  demands  of  the  manufacturing  task  and  the  manufacturing  facility  and 
equipment  required  to  accomplish  it.  Part  of  the  result  of  the  manufacturing  feasibility 
evaluation  is  the  identification  of  manufacturing  technology  needs.  The  needs  are 
identified  so  that  the  kinds  of  manufacturing  capabilities  that  will  be  required  can  be  put 
on  line  in  the  factory  prior  to  the  production  phase.  When  manufacturing  technology 
development  programs  involve  some  risk,  the  program  manager  should  consider  requiring 
the  design  contractor  to  identify  (or  develop)  fall-back  positions  for  each  of  the  risk  areas 
and/or  demonstrate  the  required  capability  in  the  laboratory  or  in  pilot  production. 

D.  Develop  Manufacturing  Strategy 

Program  manufacturing  strategy  is  a  subset  of  the  overall  acquisition  strategy. 
Specific  decisions  need  to  be  made  concerning  the  level  of  competition  that  is  to  be 
attained  during  the  production  phase.  If  the  program  will  be  dual-sourced,  the  early 
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planning  must  take  into  account  the  strategy  for  acquiring  the  necessary  data  rights  and 
for  assuring  that  capable  suppliers  exist.  New  manufacturing  technologies,  if  required  by 
the  system  concept,  will  require  specific  plans  for  development,  proof  and  transition  of 
the  technology  to  the  eventual  producer.  This  effort  will  necessitate  close  coordination 
with  the  Service  manufacturing  technology  organization  to  assure  compatibility  of  the 
technology  development  schedule  with  the  system  development  schedule.  Many  studies 
have  shown  that  competition  makes  a  major  contribution  to  reducing  weapon  system 
cost.  If  competition  is  to  be  effective,  it  must  result  from  the  application  of  a  clearly 
defined  strategy  to  ensure  that  an  environment  of  true  competition  can  be  established 
and  maintained. 

n.  CONCEPT  DEMONSTRATION  AND  VALIDATION  PHASE: 

A.  Reassess  Production  Feasibility 

Production  feasibility  is  the  likelihood  that  a  system  design  concept  can  be  pro¬ 
duced  using  existing  production  technology  while  simultaneously  meeting  quality,  pro¬ 
duction  rate  and  cost  requirements.  As  a  follow-on  to  the  feasibility  assessment  accom¬ 
plished  during  the  concept  exploration/definition  phase,  the  program  office  should  use 
the  increasingly  more  complete  description  of  the  system  to  update  the  assessment.  This 
may  be  done  within  the  program  office  or  by  the  prime  contractor(s).  As  the  system 
design  concept  and  manufacturing  approach  are  validated,  and  design  decisions  are 
made,  the  amount  of  flexibility  on  the  choice  of  production  technologies  decreases.  It  is 
important  for  the  program  manager  to  ensure  that  design  decisions  reflect  currently 
available  production  technology.  Consideration  of  feasibility  must  occur  in  a  bounded 
environment.  The  primary  bounds  are  the  existing  state  of  production  technology,  the 
cost  targets  established  for  the  system,  and  the  production  rate  and  schedule  require¬ 
ments. 

Feasibility  assessment  is  useful  in  supporting  decisions  concerning  which  of  the 
competing  system  designs  should  be  carried  into  Full-Scale  Development  ( FSD ).  It  is 
also  used  to  determine  which  of  the  manufacturing  processes  should  be  proofed  during 
FSD  and  the  nature  of  the  proofing  required.  The  process  of  weapon  system  design  is 
dynamic,  and  the  search  for  the  best  solution  often  involves  changes  to  the  design  con¬ 
cept  which  can  impact  the  manufacturing  processes  to  be  used.  Failure  to  assess  feasibil¬ 
ity  at  a  number  of  points  during  the  acquisition  process  can  result  in  accepting  changes 
to  the  design  which  are  incompatible  with  the  capability  of  the  industrial  base. 

B.  Accomplish  Production  Risk  Resolution 

Production  risk  resolution  involves  demonstrating  the  attainability  of  the  levels  of 
manufacturing  capability  required.  During  this  phase,  it  is  not  necessary  that  all  the 
details  of  the  production  processes  be  demonstrated.  The  areas  that  represent  advances 
beyond  the  current  capability  should  be  demonstrated  in  environments  which  are  some¬ 
what  representative  of  the  production  floor.  The  focus  is  on  determining  that  there  is  a 
reasonable  expectation  that  the  manufacturing  materials  and  processes  which  will  be 
required  can  be  obtained,  or  fabricated  in  sufficient  quantity  and  quality,  to  meet  the 
production  phase  requirements.  Deferring  risk  resolution  to  a  later  phase  incurs  a  con¬ 
cern  that  the  design  will  have  to  go  into  production  relying  on  the  processes  or  materials 
which  have  relatively  unpredictable  processing  time  and  cost.  There  is  the  possibility 
that  compromising  efforts  to  meet  quality,  cost,  and  schedule  goals  may  adversely  affect 
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technical  performance  of  the  end  item. 

C.  Complete  Manufacturing  Technology  Developments 

For  those  technologies  identified,  during  the  concept  exploration  phase,  as  requir¬ 
ing  development,  laboratory  demonstrations  should  be  accomplished.  As  with  the  sys¬ 
tem  development  program,  the  manufacturing  technology  development  often  represents  a 
phased  approach  to  definition  and  demonstration.  The  technology  developer  should 
demonstrate  that  the  required  process  or  material  capability  is  attainable  under  labora¬ 
tory  or  controlled  conditions  and  also  describe  the  procedure  by  which  the  technology 
can  be  extended  into  the  manufacturing  shop  environment.  Since  it  is  normally  antici¬ 
pated  that  critical  processes  will  be  demonstrated  in  the  production  environment  during 
the  full  scale  development  phase,  it  is  important  that  the  laboratory  (or  controlled  pro¬ 
duction)  process  capability  be  demonstrated  during  this  phase.  Failure  to  do  so  may 
increase  the  risk,  during  FSD,  that  the  material  or  process  may  be  found  not  to  be  a 
viable  approach  for  meeting  the  weapon  system  design  requirements. 

D.  Preliminary  Producibility  Planning 

Producibility  is  a  measure  of  the  relative  ease  of  producing  a  product  or  system. 
It  is  also  an  engineering  function  directed  toward  generating  a  design  which  is  compatible 
with  the  manufacturing  capability  of  the  defense  industrial  base.  Each  competing  design 
needs  to  be  evaluated  from  a  producibility  standpoint.  The  producibility  effort  must 
take  into  account  the  quantity  of  units,  or  systems,  to  be  produced  and  the  rate  at  which 
they  will  be  manufactured,  since  quantity  and  rate  determine  the  magnitude  of  the 
potential  manufacturing  efficiencies  to  be  gained,  or  problems  to  be  avoided.  Producibil¬ 
ity  evaluations  will  serve  as  a  basis  for  estimating  the  likely  manufacturing  cost  and 
assessing  the  level  of  manufacturing  risk  of  the  system.  Results  of  these  assessments  will 
support  the  development  of  specific  contractual  provisions  for  the  full-scale  development 
phase.  Specific  requirements  may  be  identified  based  upon  the  specific  system  designs, 
and  the  potential  for  manufacturing  cost  reduction,  through  an  aggressive  producibility 
program. 

E.  Develop  Production  Readiness  Review  Plan 

One  of  the  major  program  office  tasks  during  the  full-scale  development  phase  is 
the  Production  Readiness  Review  ( PRR ).  It  is  critical  that  the  specific  requirements  for 
contractor  planning  and  support  to  the  PRR  be  included  in  the  FSD  contract.  There  is 
also  a  need  to  ensure  that  the  necessary  government  evaluation  skills  are  available  during 
FSD.  These  needs  can  only  be  met  if  the  major  readiness  issues  are  identified  during  the 
DEMVAL  phase  and  the  methods  for  evaluating  readiness  are  clearly  defined.  The  readi¬ 
ness  issues  must  cover  both  the  defense  system  design  and  the  production  planning 
required.  Since  many  of  these  issues  are  normally  evaluated  as  part  of  the  continuing 
process  of  design  and  program  reviews,  the  planning  for  PRR  should  clearly  describe  how 
the  outputs  and  analyses  of  these  reviews  can  be  applied  to  the  PRR  tasks. 

HI  FULL  SCALE  DEVELOPMENT  PHASE: 

A.  Complete  Manufacturing  Plan 

At  the  end  of  the  FSD,  all  of  the  information  necessary  to  accomplish  the  detailed 
manufacturing  operations  for  the  system  should  be  available.  This  information  should 
be  described  in  a  manufacturing  plan  covering  the  issues  of  manufacturing  organization, 
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make  or  buy  planning,  subcontract  management,  resources  and  manufacturing  capabil¬ 
ity,  and  the  detailed  fabrication  and  assembly  planning.  The  plan  should  also  describe 
the  types  of  Government  Furnished  Property  (CiFP)  required  and  the  specific  availability 
dates  for  it.  The  contractor  management  control  system  plans,  including  those  for 
configuration  management,  the  control  of  subcontractors,  and  manufacturing  perfor¬ 
mance  evaluation  should  be  described  in  sufficient  detail  for  the  program  office  to  deter¬ 
mine  their  expected  utility.  The  plan  should  also  include  consideration  of  the  potential 
requirements  for  industrial  preparedness,  including  surge  capability  during  the  produc¬ 
tion  phase,  and  the  post- production  phase  requirements  for  support  of  the  system  in 
combat  situations.  The  development  of  this  formal  manufacturing  plan  contributes 
value  to  the  program  from  two  standpoints.  The  primary'  benefit  accrues  from  the  fact 
that  the  contractor  has  to  crystallize  the  manufacturing  planning  to  a  point  where  it  can 
be  described  in  the  detail  required.  The  secondary  benefit  is  the  usability  the  plan  pro¬ 
vides  to  the  program  management  office  personnel.  It  serves  as  a  basis  for  a  structured 
review  of  the  contractor  approach,  and  the  expected  cost  of  the  production  phase  effort, 
and  for  a  full  assessment  of  manufacturing  risk.  Where  such  a  plan  is  not  developed 
during  the  FSD  phase,  there  is  often  unnecessarily  high  cost,  and  schedule  turbulence  at 
the  front  end  of  the  production  phase. 

B.  Accomplish  Producibility  Engineering  and  Production  Planning 

Producibility.  as  noted  above,  is  a  measure  of  the  relative  ease  of  producing  a  pro¬ 
duct  or  system.  Producibility  studies,  and  analyses  of  the  alternatives,  are  conducted  by 
the  contractor  with  consideration  of  the  impact  on  cost,  schedule,  technical,  and  support 
performance.  Among  the  alternatives  available,  the  most  efficient  manufacturing  materi¬ 
als,  methods,  and  processes  should  be  selected.  Early  production  planning,  based  on 
design  and  schedule  requirements  is  essential,  if  production  delivery  schedules  are  to  be 
fulfilled.  Production  planning  must  include  identification  of  potential  problems,  with  an 
assessment  of  the  capability  required  to  produce  the  item,  and  industry’s  current  capabil¬ 
ity  to  manufacture  the  system  as  designed.  Potential  production  problems  that  require 
further  resolution  by  study  or  development  must  be  identified  and  action  for  resolution 
initiated.  The  producibility  engineering  and  planning  effort  also  results  in  the  definition 
and  design  of  the  special  tooling  and  test  equipment  required  to  execute  the  production 
phase  effort,  as  well  as  the  preparation  and  release  of  the  manufacturing  data  package, 
required  for  the  start  of  manufacture. 

There  are  a  number  of  factors  to  be  considered  in  ensuring  the  producibility  of  a 

design: 

1.  Libera!  tolerances  (dimensions,  mechanical,  electrical). 

2.  Use  of  materials  that  provide  optimum  machinability.  formability  and 
weldability. 

3.  Shapes  and  forms  designed  for  castings,  stampings,  extrusions,  etc. 
that  provide  maximum  economy. 

4.  Inspection  and  test  requirements  that  are  the  minimum  needed  to 
assure  desired  qualify  and  maximum  usage  of  available  and  standard 

inspection  equipment. 

b.  Assembly  by  efficient,  economical  methods  and  procedures. 

6.  Minimized  requirements  for  complex  nr  expensive  manufacturing  tooling 
or  special  skills. 


13-8 


There  should  be  evidence  that  the  contractor  has  accomplished  producibility  ana¬ 
lyses  of  various  options  for  the  manufacturing  task.  The  FSD  phase  results  in  the  sys¬ 
tem  design  for  entering  production.  As  the  design  evolves  during  FSD,  its  producibility 
should  be  subjected  to  regular  review  (normally  as  part  of  the  design  review  process). 

C.  Develop  Detailed  Production  Design 

Prior  to  release  of  drawings  to  the  manufacturing  location,  the  detailed  design 
drawings,  bills  of  material,  and  product  and  process  specifications  must  be  completed. 
Further,  it  is  essential  that  design  reviews  be  conducted,  to  assure  that  the  contractor  is 
complying  with  the  design  requirements,  and,  meeting  the  cost/design  goals.  The  final 
design  definition  is  the  result  of  the  performance  requirements,  the  outcomes  of  the  test¬ 
ing  accomplished,  producibility  studies  and  other  design  influences.  The  production 
phase  effort  requires  that  the  design  be  specified  to  a  very  low  level  of  detail,  so  that  the 
required  processes,  and  resources,  can  be  identified  and  obtained. 

D.  Accomplish  Production  Readiness  Review  ( PRRs ) 

The  objective  of  a  PRR  is  to  verify  that  the  production  design  planning,  and 
associated  preparations  for  a  system,  have  progressed  to  the  point  where  a  production 
commitment  can  be  made,  without  incurring  unacceptable  risks  of  breaching  thresholds 
of  schedule,  performance,  cost,  or  other  established  criteria  (DODI  5000.38).  PRRs 
should  be  conducted  by  the  program  manager,  as  a  time-phased  effort,  that  will  span 
full-scale  development  and  encompass  the  develop/producer  and  major  subsystem  sup¬ 
pliers.  The  PRR  examines  the  developer's  design  from  the  standpoint  of  completeness 
and  producibility.  It  examines  the  producer’s  production  planning  documentation,  exist¬ 
ing  and  planned  facilities,  tooling  and  test  equipment,  manufacturing  methods  and  con¬ 
trols,  material  and  manpower  resources,  production  engineering,  quality  control  and 
assurance  provisions,  production  management  organization,  and  controls  over  major  sub¬ 
contractors.  The  results  of  the  PRR  support  the  program  manager’s  affirmative  decision 
at  the  production  decision  point;  i.e.,  that  the  system  is  ready  for  efficient  and  economi¬ 
cal  rate  production. 

IV.  PRODUCTION  AND  DEPLOYMENT  PHASE: 

A.  Execute  Manufacturing  Program 

The  primary  function  of  the  production  phase  is  to  complete  the  manufacture  of 
the  defense  system  within  the  established  time  and  cost  constraints.  Normally,  the  pro¬ 
duction  rate  is  structured  to  start  slowly  and  build  into  a  defined  steady  state  rate. 
Much  of  the  same  type  of  evaluation  of  contractor  planning  for  initiation  of  the  produc¬ 
tion  phase  (generally  through  the  PRR)  needs  to  be  focused  on  the  contractor  planning 
to  increase  to  the  defined  rate.  The  program  manager  also  needs  to  focus  attention  on 
the  levels  of  engineering  change  activity.  An  excessive  number  of  engineering  changes 
can  disrupt  the  structure  of  the  manufacturing  planning  and  result  in  high  manufactur¬ 
ing  costs.  Also,  attention  needs  to  be  given  to  ensuring  that  acceptance  criteria  for  the 
product  or  system  are  clearly  specified  and  that  there  is  minimum  use  of  waivers,  devia¬ 
tions  and  Material  Review  Board  actions  during  the  acceptance  process.  The  program 
office  manufacturing  personnel  should  participate  in  the  Physical  Configuration  Audit 
{PC A)  when  the  as  built  item  is  compared  with  the  technical  documentation.  Upon  satis¬ 
factory  completion  of  the  PCA,  the  primary  acceptance  criteria  will  be  the  physical  and 
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test  requirements  listed  in  the  technical  documentation.  The  completion  of  the  produc¬ 
tion  phase  normally  involves  a  series  of  contract  actions  (associated  with  each  production 
lot)  which  will  need  to  be  planned  and  completed  to  fill  the  system  acquisition  objective. 
For  each  of  these  contracts,  a  decision  will  need  to  be  made  on  the  contract  type,  the 
incentive  structure,  if  any,  the  level  of  government  control  and  the  desired  program  visi¬ 
bility. 

B.  Maintain  Production  Surveillance 

One  of  the  primary  program  management  tasks,  during  this  phase,  is  to  establish 
and  maintain  a  system  for  accomplishing  surveillance  over  the  progress  of  the  contractor 
performing  the  manufacturing  tasks.  Generally,  the  program  manager  will  want  to 
ensure  that  information  is  available,  to  measure  contractor  effectiveness  from  time,  cost 
and  technical  achievement  standpoints.  The  program  manager  must  also  choose  between 
a  formally  structured,  and  contractually  specified,  management  control  system  or  a 
currently  existing  contractor  system.  When  problems  occur  during  the  production  phase, 
the  management  control  system  should  provide  timely  information  to  the  program 
manager  in  a  format  that  will  support  decision  making  and  action  processes. 

C.  Implement  Product  Improvement 

The  Follov-On  Operational  Test  and  Evaluation  ( FOT&E ),  and  the  initial  user 
feedback  on  the  system,  often  identify  areas  where  improvements  can  be  made  to  the  sys¬ 
tem  to  allow  it  to  better  meet  the  constantly  changing  operational  environment.  The 
challenges  for  the  program  manager  involve  the  decisions  on  which  of  these  improve¬ 
ments  to  make,  and  the  method  of  incorporating  them,  on  the  production  line.  To 
minimize  production  cost,  the  number  of  engineering  changes  should  be  kept  to  a 
minimum;  but,  operational  requirements  often  militate  in  favor  of  change.  A  program 
may  also  involve  preplanned  product  improvement.  If  this  acquisition  strategy  applies, 
when  and  how  to  incorporate  such  improvements  must  be  resolved  early  in  the  program. 

MANUFACTURING  INITIATIVES 

I.  Industrial  Modernization  Incentive  Program  (IMIP) 

IMIP  received  its  initial  impetus  during  the  late  1970s.  At  that  time  there  was 
significant  national  concern  over  the  declining  industrial  base,  especially  in  the  defense 
sector.  Classical  forces  of  competition  were  insufficient  to  stimulate  productivity-related 
investments.  Further,  DOD  business  arrangements  did  not  always  provide  adequate 
incentives  for  productivity  investments.  In  a  search  for  ways  to  motivate  contractors  to 
improve  their  productivity,  the  Air  Force  developed  Tech  Mod  (or  technology  moderniza¬ 
tion),  and  the  army  developed  what  it  called  industrial  productivity  initiatives. 

In  1982,  the  term  IMIP  was  coined  in  an  attempt  to  combine  these  endeavors  into 
an  integrated  DOD-leve!  effort.  A  test  period  began  during  which  waivers  to  acquisition 
regulations  were  considered,  new  and  unique  ways  of  contracting  were  developed,  and 
new  methods  were  established  to  derive  incentives  and  share  them  with  contractors.  By 
1985,  DOD  Directive  5000.44,  and  a  DOD  guide  for  the  implementation  of  IMIP  were 
under  development.  These  documents  established  IMIP  as  a  DOD  program  to  systemati¬ 
cally  implement  new  technologies  into  the  defense  industry. 
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The  definition  of  IMIP  has  two  important  charset  First.  1MIP  is  a  joint 

venture  —  a  cooperative  effort  between  government  and  industry,  ^ood.  IMIP  involves 
the  negotiation  of  a  business  deal  between  partners  whereby  earh  partner  contributes 
funds  and  assumes  risks,  but  also  shares  benefits  in  a  **w  ••  fashion. 

IMIP  has  short  term  as  well  as  King  term  objectives*:  short  term  objectives  include 
increased  product  quality,  reduced  lead  times  and  lower  costs  for  our  weapon  systems. 
The  long  term  objective  is  a  strong,  healthy  industrial  base  that  can  meet  surge  and 
mobilization  requirements,  should  a  conflict  or  war  arise. 

IMIP  programs  are  accomplished  in  three  phases.  Phase  I  begins  with  a  Top 
down  factory  analysis.  This  analysis  evaluates  the  needs  >f  the  overall  facility,  locales 
bottlenecks,  and  identifies  potential  manufacturing  technologies  and  modernization 
opportunities  which  apply  to  the  type  of  work  normally  done  at  that  factory. 

Phase  II  develops  the  enabling  technologies  and  work  centers  that  are  needed  to 
take  advantage  of  the  opportunities  identified  during  phase  |.  Prototypes  are  built,  and 
their  use  is  demonstrated,  during  a  formal  review  attended  bv  the  government.  Plans  for 
implementing  the  new  technologies  onto  the  prtxluetion  Hue  ar<-  also  accomplished. 

Phase  III  implements  the  IMIP  thr«  ugh  contractor  purchase  and  installation  of 
capital  equipment  in  the  facw>r\.  Actual  benefits  are  monitored.  As  they  accrue,  incen¬ 
tives  flow  to  the  contractor:  savings  flow  t<*  th»*  government:  and  the  new  technology  is 
made  available  for  transfer  to  other  interested  defense  contractors. 

Funding  of  these  endeavors  is  shared  between  the  government  and  industry.  For 
example,  during  fiscal  year?  1981  -  1087.  $1.9  billion  has  been  invested  within  Aeronauti¬ 
cal  Systems  Division  alone.  Of  that  amount,  private  industry  has  invested  about  $1.5 
billion,  or  roughly  four  times  that  which  »hc  government  has  invested.  Validated  savings 
thus  far  exceed  a  quarter  of  a  billion  dollar?.  However,  most  IMIP  projects  have  not  yet 
entered  phase  III.  The  projected  saving?  over  the  next  decade  is  about  $5  billion,  or  over 
two  and  a  half  times  the  original  investment. 

While  our  experience  is  still  somewhat  limited,  documented  results  of  this  pro¬ 
gram  appear  to  promise  a  strong,  positive  impact  on  the  industrial  base. 

II.  WORK  MEASUREMENT 

In  the  early  1970s,  Mlly-.STD-I5fi7  was  developed  to  provide  a  framework  for  dis¬ 
ciplined  work  measurement  systems  on  defense  contracts.  Faced  with  increasing  costs, 
and  decreasing  buying  power,  the  DOD  hoped  to  take  the  guess-work  out  of  estimating 
costs,  and  to  actually  reduce  costs. 

The  following  discussion  highlights  the  essence  of  what  work  measurement  is  all 
about.  First,  it  is  a  method  for  evaluating  efficiency  that  determines  the  amount  of  time 
it  should  take  to  do  a  given  job.  This  "should  take"  time  is  expressed  by  what  is  com¬ 
monly  known  as  a  labor  time  standard.  Next,  the  actual  time  needed  to  do  the  job  is 
measured  and  compared  to  the  standard.  This  comparison  is  normally  expressed  one  of 
two  ways:  If  standard  hours  are  divided  by  the  actual  hours  taken  to  do  the  job,  the 
result  is  an  efficiency  rating.  Within  the  defense  industry,  you  are  likely  to  hear  refer¬ 
ence  to  the  other  type  of  comparison,  which  simply  inverts  the  equation,  and  calls  the 
result  a  performance  index  or  realization  factor. 
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Oar  d. ■liititi ..a  .  f  *.,.-k  i.  •  t  umiKin  i*  not  complete  until  we  have  analyzed  the 
rwuliH  of  ih.-  o.mp -tri^n  •  •n>lir*t  and  actual  performance.  Whenever  efficiency 

is  low.  or  the  perform:.!...-  ».  ln  i-  high.  w.-  have  what  U  known  as  variance.  Since  this 
information  is  collect.  I  at  various  levels  in  the  work  breakdown  .structure,  it  is  possible 
lo  pinpoint  areas  in  tie-  factory  where  problems  and  inefficient  tes  may  exist,  (-orrection 
of  t he*e  problems  may  »n\..|v.-  training  of  workers,  method  improvements,  revised  layout 
of  the  facility .  ch  u.««>  it  m  .nag.-n.-  m  j  -  .odures.  or  changes  to  whatever  else  the  source 
of  the  probh-m  turn'  •  ut  *  !*»•. 

y,  mfii* t, tii«  i,  :i  |.4t,. >r  st i.*liiie>  tie*  amount  of  time  that  a  given  task 
should  take  II*  w-*.  »t.  *r<-  addition  .1  r*  *piirem.‘Uts  that  must  he  met  if  we  are  to 

have  a  standard  that  .■  ••«  I*  apple- 1  :.* -.irately  and  consistently.  The  following 
definition  fully  ;-.*-r:>>.-  all  tl.  h  .r  u  ti  ri'ii*  '  of  valid  labor  time  standard: 

•t  labor  tfnr  >f,;. i  </ 1  ?;  n  t  .**  the  twit  il  should  take  a  normally  skilled  opera¬ 
tor  (oltiiu mg  •*■  -i  t  ii.f  e  i  ii  Oon!  working  at  a  normal  all-day  level  of  effort,  lo 
rnie.pfr’t  <■  dr  •ft:  f>s-!  i  ill.  it  i  •'pt,.h(f  ipnilty 

\*.te  tb  t-  i‘  -  ;  ar  \  •  i - f  of  effort  ini]  lies  something  that  we  haven't  men¬ 
tioned  vi  f  V  Hiati.I.i'  I  i-  :•  i  *  *i  of  t  in*  sum  of  what  is  called  the  normal  time 

needed  i >  ,i  ■  i  j  •«:  •  •  a<i  ii  .  n;  •*»  for  uiiou  ti net's.  These  allowances  recognize 

three  f  «  ’  ,r,  t  r.v  •  -  ’  v.  •  1 1 ;  •  rn  <■ !  for  j  rsonal  time  (to  use  the  rest¬ 
room.  v  t  .•  •  •  ...  •  ••  .-.a-  a.s  in*  lay  wear-  on:  and  (3)  minor,  una¬ 
voidable  l-l  »y-  r  control.  Therefore,  normal  time,  plus 

some  i ■  •  *  *  * : i * ' *  ^ •  ’•  *•'.'■  •  '•  .!*  *.  -t  iiciar  I  liin'*. 

Mil r.f  .  W  *  :t-:  ,  :al  document  for  implementing  work  meas¬ 
urement.  rn  ,•>  •  •'  .<  1  ,rds.  p-fi-rr  1  to  as  type  1  and  type  II.  Type 

I  stan  bir  !-  .r.  *•  ri  .  ’  .  ; i . •  *  r  f  . . ogniyd  industrial  engineering  techniques 

such  a.-  linn  *i  !y .  '*  ;. t  i;,-*.  •iamlard  data,  and  work  sampling. 

Karh  f  •-<- 1 1 : .  |  •  so  lias  -p.  ,‘i-  -•  •  :/  a*.  >vi  :*;  ;  cations. 

Typ»-  Ii  sta».-i.:  *  •  •-•it..  -  *-  i  as.  d  on  experience  and  historical  projections. 

W  hile  l-s..  r  i  •  I  ir<  e!i-  tiv  during  the  early  phases  of  a  program 

and  wb»  i.  it  v  •  *  '.'••  t  •  ..1  j  a  type  I  standard  for  a  complex,  low- 

v*  liutrie  t  a>k . 

I ><  >| »  i  .  .  i  •'•«'■•  ;  ‘  is  from  work  measurement  programs:  By 

k  :><  wa.:  ;•  .p-  ;•  '  a  t--  k  should  fake,  it  is  possible  to: 

hrtpror/  ■  ...  1  i  >  ‘ ■  -  / 

--  hnpron  !>•'  <,■  t  unit  ■:  unrl  1 1 1  thinitl y  of  DOD  budget  requests 

--  /mpin :  f  -i  /, .  d  iii  tn.  ; •< ./  <>!h' ’  man  viacl  :i  ring  control  artnities 

-  Help  •■■  fie  ;  ,.••  o'  loij'i •  •  tw'i  -i.atr  rmi  handling  problems  by  providing 
accurate  Jiyurcs  fto  ahor  i./  » t,uipnn  -n 

Through  variance  on/vysi.-:.  or  the  performance  analysis  referred  to  earlier,  it  is 
fiossible  to: 

--  Reduce  ro*t\ 

--  Improve  maniijtirhn inq  methods  and  processes 

--  Rfducr  scrap  and  'taste 

--  V.voluatc.  ieorl.tr  p>  r formatter  and  establish  wage  incentives 
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A  final,  but  important,  question  to  ask  is,  Do  work  measurement  programs  pay  for 
themselves?  Private  industry  lias  resisted  the  implementation  of  work  measurement  on 
DOD  programs,  in  part,  because  they  are  afraid  that  the  system  will  grow  into  a  costly, 
burdensome  reporting  nightmare.  The  government  takes  a  more  positive  view,  estimat¬ 
ing  that  the  savings  potential  ranges  from  ten  to  twenty  percent  of  direct  labor  cost, 
while  the  cost  of  work  measurement  programs  is  about  one  to  four  percent  of  direct 
labor.  We  are  still  gaining  experience  in  this  area,  but  industry  surveys  suggest  savings 
to  cost  ratios  of  from  2:1  to  5:1.  Only  time  will  reveal  whether  industry  fears  of  a  costly 
and  burdensome  reporting  system  are  well  founded. 

HI.  Transition  from  Development  to  Production: 

Our  final  subject  addresses  an  area  that  is  highly  likely  to  become  institutionalized 
as  a  way  of  doing  business  by  all  three  military  services.  In  1982,  Mr.  Will  Willoughby 
was  selected  as  chairman  of  a  Defense  Science  Board  task  force  on  the  subject  of  transi¬ 
tion  from  development  to  production.  W  e  have  the  results  of  that  study  available  to  us 
in  DOD  manual  4245.70-OM.  dated  September  1985.  Two  things  about  the  approach 
taken  by  the  task  force  are  particularly  appealing:  First,  the  results  are  practical.  In  the 
words  of  Mr.  Willoughby,  many  acquisition  studies  have  gone  cosmic,  that  is,  they  have 
made  suggestions  that  are  beyond  the  ability  of  program  managers,  or  even  the  DOD 
itself,  to  control.  This  study  offers  specific  tools  that  managers  can  employ  within  the 
existing  system.  We  don't  have  to  rely  on  the  unlikely  possibility  that  someone  else  will 
change  the  system  for  us.  Second,  this  approach  integrates  the  entire  acquisition  process 
rather  than  sub-optimizing  on  only  one  aspect  of  it.  The  remainder  of  the  article 
describes  the  problems  that  needed  to  be  solved  and  the  tools  that  the  task  force  pro¬ 
vided  to  do  so. 

Ari  often  discussed  aspect  of  the  acquisition  process  is  the  length  of  time  it  takes 
to  develop  and  deploy  weapon  systems.  All  hough  there  have  been  numerous  attempts  to 
shorten  this  cycle,  if  anything,  it  has  only  grown  longer.  The  reasons  for  shortening  the 
cycle  are  directed  mainly  toward  cost,  and  to  some  extent  --  though  not  enough  -- 
toward  readiness.  Although  the  long  acquisition  cycle  is  certainly  not  desirable,  it  might 
be  tolerable  if  the  process  yielded  satisfactory  results.  But,  many  new  weapon  systems 
do  not  perform  as  originally  advertised  and,  often  require  burdensome  maintenance  and 
logistics  efforts. 

Often,  the  first  evidence  of  weapon  system  problems  does  not  become  apparent 
until  the  program  attempts  to  transition  from  full  scale  development  into  production. 
Most  acquisition  managers  seem  to  recognize  that  there  is  a  risk  associated  with  the  tran¬ 
sition  but  may  not  know  the  magnitude  nor  t  he  origin.  The  task  force  felt  that  some  of 
this  uncertainty  occurs  because  the  transition  is  not  a  discrete  event,  but  a  process  com¬ 
posed  of  three  elements:  design,  test  and  production.  Many  programs  simply  cannot 
succeed  in  production,  despite  having  passed  the  required  milestone  reviews.  A  poorly 
designed  product  cannot  be  efficiently  tested,  produced,  or  deployed.  In  the  test  program 
there  will  be  far  more  failures  than  should  be  expected.  Manufacturing  problems  will 
overwhelm  production  schedules  and  costs.  The  best  evidence  of  this  is  the  hidden  fac¬ 
tory  syndrome,  with  its  needlessly  high  redesign  and  rework  costs. 

Corrective  measures  by  DOD  have  focused  on  various  management  checkpoints 
and  review  activities.  Gradually,  numerous  layers  of  management  have  been  added  that 
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have  tended  to  compartmentalize  and  polarize  the  major  areas  of  the  acquisition  process: 
design,  test  and  production.  The  task  force  concluded  that  the  causes  of  acquisition  risk 
are  more  technical  than  managerial.  The  key  to  reducing  risk  is  in  disciplined  engineer¬ 
ing  throughout  these  interrelated  processes  of  design,  test  and  production.  Failure  to  do 
well  in  one  area  will  result  in  failure  to  do  well  in  the  other  areas. 

The  task  force  members,  represented  by  l)OL)  as  well  as  private  industry,  drew 
upon  their  combined  experience  to  generate  a  matrix  of  critical  events  in  the  design,  test, 
and  production  processes.  These  events  were  then  transformed  into  templates.  A  tem¬ 
plate  describes  three  things  for  each  event:  (1)  areas  of  risk,  (2)  an  outline  to  reduce  the 
risk,  and  (3)  a  timeline  that  shows  when  the  activity  should  occur  during  the  acquisition 
cycle.  Risk  is  introduced  to  the  program  whenever  a  particular  template  activity  begins 
late  or  does  not  finish  on  time.  The  major  areas  of  funding,  design,  test,  production, 
facilities,  logistics,  and  management  were  chosen  through  analysis  of  recurring  problems 
on  a  substantial  number  of  programs.  Funding  was  presented  first  because  it  influences 
every  other  template  in  the  transition  document. 

There  is  a  wealth  of  information  and  experience  reflected  in  the  templates.  The 
manual  that  documents  this  information,  ROD  4245-70-OM,  should  be  a  key  reference 
available  to  all  acquisition  managers.  Ciood  luck  in  a  very  challenging  career  field.  On  a 
final  note,  in  your  endeavors  to  integrate  knowledge  of  many  diverse  subjects,  I  urge  you 
to  take  advantage  of  the  expertise  available  through  your  co-located  manufacturing 
representative. 
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A  SYSTEM  DESIGN  CONCEPT  IMPLIES  CERTAIN: 


-  RAW  MATERIALS 

-  PRODUCT  TECHNOLOGIES  ( VHSIC) 

-  MANUFACTURING  TECHNOLOGIES  (ELECTRON  BEAM  WELDING) 

*** 

POTENTIAL  TECHNOLOGIES 


THERMOPLASTIC-MATRIX 
COMPOSITES /BISMALEMIDES 

COMPOSITES  OUT  OF  AUTOCLAVE 
BONDING 

ALUMINUM-LITHIUM  ALLOYS 
VHSIC 

POWDER  METALLURGY 

GRAPHITE/EPOXY  COMPOSITES 

ELECTRON-BEAM- WELDING  OF  TI 

TITANIUM  NEAR-NET  SILAPE 
TECHNOLOGY 


ALUMINUM  METAL  MATRIX 
COMPOSITES 

LARGE  PRECISION  FORGINGS 

MOLDLINE  FIDELITY  TECHNOLOGY 
CARBON-CARBON  COMPOSITES 
NON-CONTACT  LASER  INSPECTION 
FUEL-TANK  SEALING 
IMIP/TECH  MOD  PROJECTS 


MANAGING  TECHNOLOGICAL  RISK 

MANTKCH  (MANUFACTURING  TECHNOLOGY) 

IMIP  (INDUSTRIAL  MODERNIZATION  INCENTIVE  PROGRAM) 
FALL-BACK  PLAN  (ALTERNATIVE  METHOD) 
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SYSTEM  APPLICATION 
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MANAGEMENT  OF  CRITICAL  ITEMS 

MATERIAL  MANAGEMENT  PROGRAM 

-  RECLAMATION/RECYCLE 

-  SUBSTITUTION 
MANTECH  PROGRAMS 
CONTRACTUAL  INCENTIVES 
ADVANCE  PURCHASES 

USE  OF  GO\ERNMENT  STOCKPILES 


*** 


RISK  CATEGORIES 

1.  STATE-OF-THE-PRACT1CE 

2.  STATE-OF-THE-ART 

3.  EXPERIMENTAL 
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IMPLEMENTED  IN  CONTRACTS  BY  ORDERING  MARKING  OF  DATA  WITH 
DISTRIBUTION  STATEMENTS  WRITTEN  ON  ALL  TECHNICAL  DATA  SUBMITTED 


(BLOCKS  8  *  16,  l)D  FORM  1423,  CAN  CITE  OR  REQUIRE  DETERMINATION  OF 
DISTRIBUTION  STATEMENT) 


Distribution  Statement  A: 
Distribution  Statement  B: 
Distribution  Statement  C: 

Distribution  Statement  D: 
Distribution  Statement  E: 
Distribution  Statement  F: 


Unlimited  Distribution 

U.S.  Government  Agencies  Only 

U.S.  Government  Agencies  and  their 
Contractors 

DOD  and  DOD  Contractors 
DOD  ONLY 

Distribution  as  directed  by  DOD  Controlling 
Office 


Distribution  Statement  X: 


U.S.  Government  Agencies  and  Private 
Individual  Enterprises  eligible  to  obtain 
export  controlled  technical  data 
IAW  10  U.S.C  140c. 


DATA  MANAGER’S  TOOLS  OF  THE  TRADE 

*  AMSDL:  Acquisition  Management  Systems  and  Data  Requirements  Control 
List  (Now  the  DOD  5010.12-L)  (formerly  was  the  DOD  5000.19-L) 

Listing  of  all  approved  Standard  DIDs 

*  DID:  Data  Item  Description  (DD  Form  1664) 

Individual  Description  of  One  Collection  of  Recorded  Information 

Standard  DID:  Scientific/Technical  (TYPE  1) 
or 

Mgmt/Administrative  (TYPE  11) 

Note:  Office  of  Management  &  Budget  (OMB)  considers  a  DID  a  Rules  Document  which 
must  have  an  OMB  Control  Number  and  Expiration  Date  Signifying  if  has  been 
Approved  by  OMB  per  the  Paperwork  Reduction  Act:  PL  06-51 1 
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PRODU CIBILIT Y  OBJECTIVES 


MAXIMIZE : 

o  SIMPLICITY  OF  DESIGN 
o  USE  OF  ECONOMICAL  MATERIALS 

o  USE  OF  ECONOMICAL,  PROVEN  MANUFACTURING  TECHNOLOGY 
o  EARLY  CONFIRMATION  OF  DESIGN  ADEQUACY 
o  PROCESS  REPEATABILITY 
o  PRODUCT  INSPECTABILITY 


MINIMIZE: 

o  PROCUREMENT  LEAD  TIMES 
o  GENERATION  OF  SCRAP  AND  WASTE 
o  USE  OF  CRITICAL/STRATEGIC  MATERIALS 
o  DESIGN  CHANGES  DURING  PRODUCTION 
o  SPECIAL  TOOLING  AND  TEST  EQUIPMENT 
o  UNIT/LIFE  CYCLE  COSTS 
o  SKILL  LEVELS  OF  PRODUCTION  PERSONNEL 


*** 


PRODUCIBILITY  PRINCIPLES 
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STANDARDIZE 


SIMPLIFY 

FACILITATE 


13-21 


PRODUCTION  READINESS  REVIEW 

PART  m  OVERVIEW 

IXIH'STIUU  MODERNS  \TU>\  IVt.Al'U  HUHiC  \\1 
WORK  MEASUREMENT 

TRANSITION  FROM  DEVELOPMENT  TO  PRODUCTION 


•  REDUCED  COST  MEANS  LOWER  PROFITS 


IMIP  -  DEFINITION 


JOINT  VENTURE 
BUSINESS  DEAL 

-  SHARED  RISK/FUNDING 

-  SHARED  BENEFIT 


IMIP  OBJECTIVES /BENEFITS 

SHORT  TERM: 

INCREASED  QUALITY  (DO  IT  BETTER) 
REDUCE  LEADTIME  (DO  IT  FASTER) 
REDUCE  COSTS  (DO  IT  CHEAPER) 

LONG  TERM: 

STRENGTHEN  INDUSTRIAL  BASE 
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PHASE  I 


TOP  DOWN  FACTORY  ANALYSIS 
DESIGN/PLAN 

COST  AND  TECHNICAL  PROPOSAL  -  PHASE  U 
NEGOTIATE  BUSINESS  DEAL 


*  *  * 

PHASE  II 

DEVELOP  TECHNOLOGIES/ WORK  CENTERS 
BUILD/DEMONSTRATE  PROTOTYPES 
PLAN  FOR  IMPLEMENTATION 


PHASE  HI 

IMPLEMENTATION 

ASSESSMENT/DISTRIBUTION  OF  BENEFITS 
TECHNOLOGY  TRANSFER 
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APPROXIMATE  IMIP  TIMING 
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I - > 

FACTORY  ANALYSIS 


Y 


BUSINESS 


DEAL 


PHASE  II 


DESIGN.  DEVELOPMENT 


H 

DEMONSTRATION 


Y 


- j 

PHASE  III 

IMPLEMENTATION 


DEM/ VAX.  FSD  PRODUCTION 

1 - 1 - ) - I 


BUSINESS  DEAL 

*  FUNDING 

*  SAVINGS 

*  VALIDATION  OF  SAVINGS 

*  INDEMNIFICATION 
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WHAT  IS  WORK  MEASUREMENT? 

METHOD  FOR  EVALUATING  EFFICIENCY 

*  DEFINES  HOURS  FOR  A  JOB*  (STANDARD) 

*  MEASURES  ACTUAL  HOURS  USED 

*  COMPARES: 

EFFICIENCY  =  STANDARD  HOURS/ACTUAL  HOURS 
VS. 

PERFORMANCE  =  ACTUAL  HOURS/STANDARD  HOURS 
*  ANALYZE  PERFORMANCE,  ADDRESS  PROBLEM  AREA 
♦♦TRAINING 
♦♦METHOD 
♦♦LAYOUT 

♦♦MANAGEMENT  PROCEDURES 

EXAMPLE 

STANDARD  HOURS  =  20  MINUTES 
ACTUAL  TIME  =  30  MINUTES 
EFFICIENCY  =  20/30  =  67% 

PERFORMANCE  =  30/20  =  1.5 
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LABOR  TIME  STANDARD 


THE  TIME  IT  SHOULD  TAKE  A  NORMALLY  SKILLED  OPERATOR 
FOLLOWING  A  PRESCRIBED  METHOD,  WORKING  AT  A  NORMAL 
ALL-DA  Y  LEVEL  OF  EFFORT,  TO  COMPLETE  A  DEFINED  TASK 
WITH  ACCEPTABLE  QUALITY. 


DOD  RECOGNIZES  TWO  CATEGORIES  OF  TIME  STANDARDS 

o  TYPE  I,  ENGINEERED  STANDARDS 
TIME  STUDY 

PREDETERMINED  DATA 

-  METHODS  TIME  MEASUREMENT  (MTM) 

-  BASIC  MOTION  TIME  STUDY  (BMT) 

STANDARD  DATA 
WORK  SAMPLING 

o  TYPE  II,  ESTIMATED  STANDARDS 

BASED  ON  EXPERIENCES /HISTORICAL  PROJECTION 
LESS  RELIABLE  -  SOMETIMES  MORE  COST  EFFECTIVE 
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APPLICABILITY 


o  FSD  PROGRAMS  EXCEEDING  $100M 

o  PRODUCTION  PROGRAMS  EXCEEDING  $20M  ANNUALLY  OR  $100M  CUM 
o  SUBCONTRACTS  EXCEEDING  $5  MILLION  ANNUALLY  OR  $25  CUM 
o  EXCLUSIONS 

-  CONSTRUCTION 

-  FACILITIES 

-  OFF-THE-SHELF  COMMODITIES 

-  TIME  AND  MATERLVLS 

-  RESEARCH 

-  STUDY 

-  NON-ACQUISITION  CONNECTED  DEVELOPMENT 

-  SHIP  CONSTRUCTION 

-  SHIP  SYSTEM  CONTRACTS 

-  SERVICE  TYPE  CONTRACTS 


BENEFITS 

ACCURATE  TIME  STANDARDS 

IMPROVE  COST  ESTIMATES 
IMPROVE  BUDGET  ESTIMATES 
IMPROVE  SCHEDULING 
IMPROVE  LAYOUT/MATERIALS  HANDLING 

PERFORMANCE  ANALYSIS: 

REDUCE  COSTS 

IMPROVES  METHODS/PROCESSES 
REDUCES  SCRAP/WASTE 
EVALUATES  WORK  FORCE 
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BENEFITS  VERSUS  COST 


o  APPLICATION  OF  MIL- STD  1567A  OFFERS  SAVINGS  POTENTIAL  OF  FROM 
10-20%  OF  DIRECT  LABOR  COST 

o  WORK  MEASUREMENT  PROGRAMS  COST  MONEY  -  A  RANGE  OF  FROM 
1-  4%  OF  DIRECT  LABOR  HOURS 

o  RATIO  OF  SAVINGS  TO  COST  VARY  FROM  2:1  TO  5:1 


TEMPLATES  -  ORGANIZATION 
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LESSON  14 


LESSON  TITLE:  Test  and  Evaluation 
TIME:  2  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  purpose  of  test  and  evaluation  and  the  organizations  involved  in 
test  and  evaluation. 

SAMPLES  OF  BEHAVIOR: 

a.  State  the  purpose  of  Development  T&E  ( DT&E ). 

b.  State  the  purpose  of  Operational  T&E  ( OT&E ). 

c.  State  the  primary  role  of  AFOTEC. 

d.  Describe  how  the  test  effort  is  integrated  into  the  acquisition  program. 

e.  List  the  documentation  associated  with  testing. 

f.  Identify  the  AFSC  test  organizations  that  can  act  as  an  RTO  or  PTO  and 
understand  their  role  in  the  DT&E  process. 

TOPIC  INTRODUCTION: 

Test  and  Evaluation  is  one  of  the  most  costly  important  areas  in  the  acquisition 
arena.  After  all,  in  order  for  us  to  get  information  to  do  analyses,  comparisons,  and 
evaluations,  we  need  information,  which  can  be  very  expensive  to  acquire.  Test  and 
Evaluation  gives  you  that  information.  Recent  acquisition  reform  legislation,  like  the 
Packard  Commission  Report,  emphasized  the  importance  of  testing  the  system  as  early  as 
possible  before  locking  into  concrete  decisions.  Lesson  14  addresses  the  concept  of  testing 
in  the  acquisition  environment.  The  purpose  of  Development  and  Operational  Test  and 
Evaluation  is  introduced,  as  well  as  how  these  activities  fit  into  the  acquisition  life  cycle. 
Next,  the  role  of  one  of  the  operational  implementers  of  test  policy,  the  Air  Force  Opera¬ 
tional  Test  and  Evaluation  Center  {AFOTEC),  and  the  documentation  that  is  important 
in  providing  test  plans  and  results,  are  addressed.  As  program  manager,  you  should  be 
concerned  about  the  test  requirements  for  your  program.  Operational  tests  can  be  very 
complicated,  time  consuming,  and  expensive.  Numerous  subjective  judgements  go  into 
validating  whether  or  not  the  threat  simulators  and  targets  really  simulate  hostile  forces, 
and  whether  the  tests  are  realistic  enough,  despite  the  artificiality  of  the  test  rules  of 
engagement. 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 

INSTRUCTIONAL  MATERIALS: 

a.  Article:  Test  and  Evaluation,  by  Major’s  Huffman,  Lozito,  and 
Snyder,  May  1981,  ACSC,  AU,  AFIT/LSY 

b.  Article:  RTO / PTO  Organizations,  by  Capt  Adler,  AFIT/LSY 
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c.  Test  and  Evaluation  videotape 

d.  Lesson  viewgraphs 


AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  DODD  5000.3,  12  Mar  86,  Test  and  Evaluation 

b.  AFR  80-14,  (3  Nov  86),  Test  and  Evaluation 

c.  AFP  55-43,  (28  Jun  85),  Management  of  Operational  Test  and  Evaluation 

d.  AFSCP  80-27  (26  Jan  81),  Summary  ofAFSC  Major  Ranges  and  Test 
Facilities 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  RTO/PTO  Organizations 

b.  Read  article:  Test  and  Evaluation 

c.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

1.  The  Department  of  Defense,  as  well  as  industry,  spends  billions  of  dollars  on 
research  and  development.  There  is  a  steady  stream  of  requests  for  more  programs  to  be 
funded  for  R&D  and  decision  makers  must  choose  which  programs  to  fund  and  which 
ones  to  drop. 

a.  What  criteria  would  you  use,  if  you  were  one  of  these  decision  makers,  to 
choose  from  among  the  programs? 

b.  What  types(s)  of  information  would  you  need,  and  how  would  you  get  this 
information? 


2.  There  are  two  types  of  test  and  evaluation  associated  with  the  acquisition  pro¬ 
cess:  Development  Test  and  Evaluation  ( DT&E )  and  Operational  Test  and  Evaluation 
( OT&E ).  What  in  your  opinion,  is  the  purpose  of  DT&E?  Can  you  provide  examples  of 
OT&E? 


3.  If  we  find,  through  DT&E,  that  a  system  or  subsystem  fails  to  meet  a 
specification,  should  we  waive  the  specification  or  enforce  the  contract? 

a.  What  do  we  mean  when  we  say  a  system  has  been  over  specified?  How  do  we 
know?  What  should  we  do  about  it? 
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b.  What  do  we  mean  when  we  say  a  system  has  been  under  specified?  How  do 
we  know?  What  should  we  do  about  it? 


(Acronyms  introduced  in  this  lesson,  and  their  description] 
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ADTC 

AEDC 

AFFTC 

AFOTEC 

JCS 

JTfcE 

JTD 

JTF 

MST&E 

PTO 

QOT&E 

QT&B 

RTO 

SAF 

TEMP 

TPWG 


Armament  Development  Test  Center 
Arnold  Engineering  t  Development  Center 
Air  Force  Flight  Test  Center 

Air  Force  Operational  Test  and  Evaluation  Center 

Joint  Chiefs  of  Staff 

Joint  Test  and  Evaluation 

Joint  Test  Director 

Joint  Task  Force 

Multi-Service  Test  and  Evaluation 
Participating  Test  Organization 
Qualifying  Operational  Test  &  Evaluation 
Qualification  Test  and  Evaluation 
Responsible  Test  Organization 
Secretary  of  the  Air  Force 
Test  and  Evaluation  Master  Plan 
Test  Plan  Working  Group 


TEST  AND  EVALUATION 

Thus  far  you  have  "survived”  the  introduction  to  the  kingdom  of  acquisition. 
Now  it  is  really  time  to  put  your  interest  to  test.  Test  and  Evaluation  commences  as 
early  as  possible  in  the  acquisition  process  and  continues  throughout  the  entire  system 
life  cycle.  Moreover,  sufficient  T&E  must  be  accomplished  successfully  before  decisions 
will  be  made  to  commit  significant  additional  resources  to  a  program  or  to  advance  it 
from  one  acquisition  phase  to  another.  While  conducting  T&E,  quantitative  data  must 
be  used  to  the  maximum  extent  possible,  thereby  minimizing  subjective  judgments. 
Well,  what  are  the  main  purposes  of  T&E?  Essentially,  they  encompass  (1)  the  assess¬ 
ment  and  reduction  of  risks;  (2)  the  evaluation  of  the  system’s  operational  effectiveness 
and  suitability;  and  (3)  the  identification  of  system  deficiencies.  As  you  can  see,  that  is 
not  only  a  mouthful  to  say,  but  also  a  Goliath  to  conquer.  Nonetheless,  the  difficulty  of 
the  task  is  probably  equal  to  its  importance  to  the  program,  for  it 

0  Allows  early  evaluation  of  program’s  technical  and  operational  feasibility. 

0  Facilitates  earlier,  less  costly  correction  of  system  deficiencies  and  shorter  schedules. 

Additionally,  at  the  DAB/AFSARC  reviews,  much  of  the  information  used  to 
assess  program  progress  is  derived  directly  from  T&E  results.  The  bottom  line  then  is 
that  the  results  from  T&E  significantly  affect  the  future  of  the  program  —  whether  it 
advances,  changes,  or  dies. 

TEST  AND  EVALUATION  DIRECTORATE  ORGANIZATION 

Within  a  Program  Office  ( PO ),  a  typical  T&E  directorate  is  not  a  simple  thing 
to  define.  Depending  on  the  number  of  programs  involved,  and  their  size  and  complex¬ 
ity,  the  organization  can  vary  from  a  deputy  director  for  large  programs,  chief  of  a  divi¬ 
sion  for  other  small  programs,  to  possibly  only  one  or  two  individuals  for  small  or  one- 
of-a-kind  programs.  In  any  case,  while  the  complexity,  schedules,  and  resource  planning 
may  change,  the  mission  of  the  organization  does  not.  Regardless  of  type  organization, 
the  "testers"  must  plan,  coordinate,  and  manage  the  program  test  activities  within  poli¬ 
cies  set  by  the  Program  Manager.  The  larger  programs  usually  require  more  schedule 
and  test  disciplines  due  to  more  test  articles  and,  possibly,  more  complex  operations. 
However,  testing  smaller  programs  should  receive  the  same  emphasis  within  the  PO  as 
the  large  programs. 

TEST  AND  EVALUATION  CATEGORIES 

Looking  at  the  kinds  of  T&E,  there  are  essentially  two:  Development  Test  and 
Evaluation  ( DT&E)  and  Operational  Test  and  Evaluation  ( OT&E ).  OT&E,  associated 
with  an  R  &  D  program,  is  further  sub-divided  into  two  phases:  Initial  Operational  Test 
and  Evaluation  ( IOT&E )  and  Follow-on  Operational  Test  and  Evaluation  ( FOT&E ). 
The  transition  point  for  these  two  phases  is  Milestone  III  (Production  decision).  Finally, 
for  certain  programs/subsystoms  such  as  non-research  and  development  funded  pro¬ 
grams,  joint  programs,  and  computer  software  subsystems,  modified  or  specialized  test¬ 
ing  requirements  apply.  Let’s  now  look  at  each  of  these  T&E  categories. 
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DEVELOPMENT  TEST  AND  EVALUATION  ( DT&E ) 

Through  DT&E,  the  Air  Force  demonstrates  that  the  system  engineering  design 
and  development  is  complete,  design  risks  have  been  minimized,  and  the  system  will  per¬ 
form  as  required  and  specified.  DT&E  includes  the  test  and  evaluation  of  components, 
subsystems,  hardware/software  integration,  associated  software,  and  pre-production 
models  of  the  systems.  It  involves  an  engineering  analysis  of  the  systems  performance, 
including  its  limitations  and  safe  operating  parameters.  Furthermore,  the  system  is 
evaluated  against  engineering  and  performance  criteria  specified  by  the  implementing 
command.  Also  addressed  are  the  logistics  engineering  aspects  (supportability,  maintai¬ 
nability,  reliability,  etc.)  as  well  as  compatibility  and  interoperability  with  existing  or 
planned  systems.  DT&E  usually  commences  in  the  Concept  Expioration/Definition 
phase  and  continues  through  the  Full-Scale  Development  phase.  Furthermore,  it  may 
embrace  testing  of  system  improvements  or  modifications  designed  to  correct  deficiencies 
or  to  reduce  life  cycle  costs.  In  summary  then,  overall  DT&E  objectives  encompass  the 
following: 

0  Assess  system  specification  compliance,  deficiencies,  compatibility, 

OT&E  readiness,  configuration  changes 

0  Assess  program  risks/tradeoffs 

0  Assess  logistics  supportability/survivability 

0  Verify  technical  order  completeness 

0  Gather  training  program  and  environmental  impact  data 

0  Determine  system  performance  limitations 

The  implementing  command,  normally  AFSC,  manages  DT&E.  AFSC  assigns  this 
responsibility  to  the  Program  Manager  {PM).  The  PM  then  designates  a  DT&E  test 
director  (sometimes  himself)  to  exercise  control  over  the  DT&E  test  team  and  associated 
resources.  Besides  the  Program  Office  ( PO ),  the  OT&E,  operating,  and  supporting  com¬ 
mands  participate  in  the  DT&E  effort  as  directed  by  program  directives  and  coordinated 
planning  documents.  (Note:  The  OT&F  command  normally,  for  major  and  HQ  USAF 
designated  non- major  programs,  is  the  Air  Force  Operational  Test  and  Evaluation 
(’enter  ( AFOTEC )  while  a  Major  Command  (MAJCOM)  is  normally  assigned  as  the 
OT&E  command  for  other  non-major  system  programs.)  In  addition  to  the  governmen¬ 
tal  agencies,  the  contractor  plays  a  key  role  in  the  DT&E,  especially  in  the  early  part  of 
the  test  program.  A  contractual  system  test  plan  is  developed  jointly  by  the  PO  and  the 
contractor.  It  identifies  the  roles  of  each  participant.  Finally,  the  specifics  on  DT&E 
management  are  documented  in  each  program’s  Test  and  Evaluation  Master  Plan 
{TEMP  —  see  discussion  later  in  chapter). 
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QUALIFICATION  TEST  AND  EVALUATION  ( QT&E ) 

QT&E  is  the  testing  performed,  in  lieu  of  DT&E,  on  programs  where  there  is  no 
research,  development,  test  and  evaluation  ( RDT&E)  funding.  These  programs  might 
include  Class  IV/V  modifications,  simulators,  software  programs,  and  off-the-shelf  equip¬ 
ment.  QT&E  is  usually  performed  by  the  implementing  command.  Essentially,  the 
same  test  policies  for  DT&E  apply  to  QT&E. 

OPERATIONAL  TEST  AND  EVALUATION  (OT&E) 

OT&E  is  the  T&E  conducted  to  (1)  estimate  a  system's  operational 
effectiveness/suitability,  (2)  identify  needed  modifications,  and  (3)  provide  information 
for  tactics,  doctrine,  computer  documentation,  technical  data,  training,  programming, 
organization,  and  personnel  requirements.  It  is  conducted  throughout  the  system  life 
cycle  in  as  realistic  conditions  as  possible.  OT&E  uses  personnel  with  the  same  type  of 
skills  and  qualifications  as  those  who  will  operate,  maintain,  and  support  the  deployed 
system.  As  previously  mentioned,  OT&E  includes  two  sub-phases:  10T&E  and 
FOT&E.  IOT&E  is  conducted  to  provide  a  valid  estimate  of  a  system’s  operational 
effectiveness/suitability  and  is  normally  completed  prior  to  the  first  major  production 
decision.  Typically,  the  OT&E  command  accomplishes  this  testing  on  pre-production, 
prototype  or  pilot  production  items.  FOT&E  is  usually  conducted  after  the  first  major 
production  decision  or  after  the  first  production  article  has  been  accepted.  It  may  con¬ 
tinue  throughout  the  weapons  systems’  life  cycle.  FOT&E  may  be  divided  into  two 
phases,  cleverly  designated  FOT&E  (I)  and  (II).  FOT&E  (I)  is  conducted  after  IOT&E 
and  is  used  to  refine  operational  suitability /effectiveness  estimates  and  to  evaluate  correc¬ 
tive  changes  made  during  IOT&E.  The  OT&E  command  determines  the  transition  to 
the  second  phase  (FOT&E  (II))  and  this  transition  varies  on  a  program-by-program 
basis.  FOT&E  (II)  measures  the  system’s  ability  to  meet  changing  operational  require¬ 
ments,  refines  operational  tactics  and  programs,  and  identifies  and  confirms  correction  of 
system  deficiencies.  In  summary,  then,  as  the  Air  Force  conducts  OT&E,  its  overall 
objectives  include 

0  Estimate  operational  effectiveness/suitability 
0  Identify  operational  deficiencies 
0  Recommend/evaluate  configuration  changes 

0  Provide  logistics  support,  training,  tactics,  operation  and  support  cost  data 
0  Determine  tech  data/support  equipment  adequacy 
0  Estimate  system  survivability 

As  discussed  under  DT&E,  the  management  of  OT&E  rests  with  either  AFOTEC  or 
MAJCOMS  depending  upon  the  program  designation.  (Note:  AFOTEC  is  the  assigned 
focal  point  for  all  AF  OT&E,  responsible  for  providing  OT&E  information  to  HQ  USAF 
and  the  Secretary  of  Air  Force  (SAF)  for  support  of  program  reviews.  As  a  result,  for 
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MAJCOM-managed  OT&E,  AFOTEC  monitors  the  program  and  approves  all  test 
plans.)  The  OT&E  Command  (AFOTEC  or  MAJCOM)  designates  and  provides  the 
OT&E  test  director,  who  exercises  control  over  the  OT&E  test  team  and  resources.  The 
OT&E  test  director  works  closely  with  the  Program  Manager  (PM)  and  informs  him 
immediately  of  any  identified  system  deficiencies.  While  the  OT&E  test  agency  is 
responsible  for  OT&E  management,  the  PM  remains  responsible  for  the  rest  of  the  pro¬ 
gram.  Before  continuing,  let’s  look  briefly  at  the  concept  of  combined  testing.  During 
the  early  test  planning  stages,  one  of  the  considerations  is  to  establish  a  test  program 
which  uses  resources  in  the  most  cost  effective  manner.  If  separate  testing  (separate 
DT&E  and  OT&E  testing)  would  cause  either  a  significant  program  delay  or  a  significant 
increase  in  cost/resources,  development  and  operational  testing  are  combined,  where  pos¬ 
sible.  This  combined  testing  will  include  both  combined  and  separate  DT&E  and  OT&E 
test  events  to  satisfy  all  of  the  test  objectives.  Moreover,  the  development  and  opera¬ 
tional  evaluations  are  performed  independently.  Test  management  responsibilities  are 
similar  to  those  previously  discussed:  the  implementing  command  manages  the  DT&E 
while  the  OT&E  command  manages  the  OT&E.  The  implementing  command  is  respon¬ 
sible  for  integrating  the  two  test  plans  together.  In  accordance  with  the  combined  test 
plan,  directors  will,  during  the  testing  efforts,  share  resources  and  provide  support  to 
each  other. 

QUALIFICATION  OPERATIONAL  TEST  AND  EVALUATION  ( QOT&E) 

Like  QT&E,  QOT&E  is  performed,  in  lieu  of  IOT&E,  on  programs  where  there 
is  no  RDT&E  funding.  Either  AFOTEC  or  the  designated  MAJCOM  conducts  the 
QOT&E.  Essentially,  the  same  test  policies  for  IOT&E  apply  to  QOT&E.  QOT&E  is 
usually  done  before  the  first  production  article  is  accepted.  However,  HQ  USAF  may 
direct  that  it  be  done  before  the  initial  production  decision.  For  one-of-a-kind  produc¬ 
tion  systems,  Air  Force  acceptance  may  come  before  QT&E  and  QOT&E.  Following 
QOT&E,  FOT&E  is  conducted,  as  appropriate. 

JOINT  PROGRAM  TEST  AND  EVALUATION 

A  joint  program  T&E  exists  when  two  or  more  services  or  Department  of 
Defense  ( DOD )  agencies  participate  in  the  testing  effort.  There  are  two  kinds  of  joint 
program  T&E:  multi-service  T&E  ( MST&E )  and  joint  T&E  ( JT&E ).  MST&E  involves 
acquisition  program  testing,  while  JT&E  involves  non-acquisition  testing. 

MULTI-SERVICE  TEST  AND  EVALUATION  -  MST&E  involves  T&E  conducted 
by  two  or  more  services  (or  DOD  agencies)  for  systems  to  be  acquired  by  more  than  one 
service.  Additionally,  MST&E  is  performed  when  one  service’s  system  interfaces  with 
equipment  of  another  service.  This  testing  may  include  either  DT&E,  or  OT&E,  or  both. 
The  lead  service,  as  directed  by  OSD,  manages  the  MST&E  effort  in  accordance  with  its 
service  regulations  (for  example,  if  the  Air  Force  was  the  lead  service,  AFR  80-14  pro¬ 
cedures  would  be  used).  If  another  service  lias  certain  unique  T&E  requirements,  devia¬ 
tions  may  be  accommodated  by  mutual  agreement. 

JOINT  TEST  AND  EVALUATION  -  JT&E  will  be  conducted  when  OSD 
(specifically  the  Office  of  the  Under  Secretary  of  Defense)  decides  it  necessary  to 
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0  Examine  the  capability  of  developmental/ deployed 
systems  to  perform  their  intended  mission. 

0  Evaluate  technical  concepts,  system  requirements, 
improvements  or  interoperability. 

0  Provide  information  for  force  structure  planning. 

0  Gather  data  on  joint  doctrine,  tactics,  or  procedures. 


Testing  will  be  accomplished  in  the  most  realistic  operational  environment  feasible. 
OSD  delegates  test  management  responsibilities  to  one  of  the  services.  The  selected  ser¬ 
vice  nominates  a  Joint  Test  Director  ( JTD )  for  OSD  approval.  The  JTD,  once 
confirmed,  is  responsible  for  developing  test  plans,  establishing  the  Joint  Task  Force 
( JTF ),  achieving  the  test  objectives,  and  preparing  the  required  reports.  He  is  assisted 
by  the  JTF,  which  consists  of  AFOTEC,  MAJCOM,  and  other  participating  agencies’ 
personnel.  The  JT&E  final  report  is  approved  by  OSD  and  distributed  to  all  the  services 
and,  the  Joint  Chiefs  of  Staff  ( JCS ). 

COMPUTER  SOFTWARE  TEST  AND  EVALUATION 

Not  a  soft  area  by  any  stretch  of  the  imagination.  During  the  acquisition  pro¬ 
cess,  quantitative  and  demonstrable  performance  objectives  must  be  set  for  computer 
software,  and  the  testing  must  be  structured  to  demonstrate  that  software  has  reached  a 
level  of  maturity  proper  to  each  phase.  For  embedded  software,  performance  objectives 
must  be  included  as  a  subset  of  the  overall  system.  The  T&E  master  plan  [TEMP  —  see 
later  discussion)  enumerates  the  software  test  objectives  and  test  management  responsi¬ 
bilities.  Before  software  is  released  for  operational  use,  it  must  undergo  sufficient  opera¬ 
tional  testing  to  adequately  estimate  the  system’s  operational  effectiveness/suitability. 
Such  testing  should  encompass  combined  hardware/software  interface  and  maintainabil¬ 
ity  testing,  using  typical  operator  personnel.  Software  objectives  will  be  included  as  a 
part  of  the  DT&E/OT&E  test  objectives.  The  importance  of  comprehensive  software 
testing  cannot  be  overemphasized. 

MAJOR  TEST  DOCUMENTATION 

The  following  list  is  by  no  means  exhaustive;  however,  it  briefly  describes  the 
key  documents  involved  in  T&E  management.  Not  listed  are  the  Decision  Coordinating 
Paper  ( DCP )  and  Program  Management  Directive  ( PMD ).  As  you  may  recall,  the  DCP 
was  the  principal  document  used  to  record  essential  program  information  for  use  in  the 
SECDEF  decision-making  process.  In  the  T&E  context,  this  document  records  critical 
issues/areas  of  risk,  accomplished  T&E  results,  etc.,  for  support  of  the  program  milestone 
decisions.  Successful  T&E  progress  is  necessary  before  the  system  can  move  into  the  next 
acquisition  phase.  The  PMD  is  the  HQ  USAF  management  directive  providing  direction 
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and  tasking  to  the  implementing  and  participating  commands.  Within  this  document, 
the  responsibilities  for  test  management  and  support  are  assigned.  Now  that  you  recall 
these  documents,  let  us  look  at  the  documents  more  intrinsic  to  the  T&E  business: 


■  0  PROGRAM  MANAGEMENT  PLAN  (PMP),  TEST  SECTION  -  In 

general,  the  PMP  is  developed  by  the  PM  and  shows  the  integrated 
time-phased  tasks/resources  required  for  the  program.  The  test 
i  section  contains  overall  test  objectives,  test  management 

concept/responsibilities,  necessary  test  resources,  and  critical 
issues  and  areas  of  risks.  Because  of  overlapping  information, 
this  section  often  references  the  TEMP  rather  than  repeat  TEMP 
material. 

0  TEST  AND  EVALUATION  MASTER  PLAN  ( TEMP)  -  Primary 
document  used  to  assess  adequacy  of  planned  T&E.  It  contains 

--  Mission/system  description 
--  Required  operational/technical  characteristics 
--  Critical  technical/operational  issues 
—  Test  management  responsibilities 
—  DT&E  and  OT&E  outlines,  to  include  objectives 
—  Test  resource  summary 

The  PM  prepares  the  TEMP  with  assistance  from  the  Test  Planning 
Working  Group  (TPWG).  This  group  consists  of  personnel  from 
the  PO,  test  agencies,  AFOTEC,  operating  and  supporting  MAJCOMS, 
contractor  (when  appropriate),  and  other  involved  test  agencies. 

Besides  providing  assistance  in  the  initial  TEMP  preparation, 
the  TPWG  meets  periodically  to  update  test  plans  and  monitor  test 
progress.  The  TEMP  is  coordinated  with  all  affected  agencies. 

For  major  systems  the  TEMP  is  approved  at  the  Under  Secretary  of 
Defense  level. 
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RTO/PTO  Organizations 

As  was  mentioned  in  the  "Test  and  Evaluation"  article,  the  implementing  com¬ 
mand,  normally  AFSC,  manages  DT<kE.  This  responsibility,  then,  for  management  of 
DT&E  rests  with  the  program  manager.  The  program  manager  is  normally  assisted  by  a 
responsible  test  organization  (iZTO)  appointed  by  HQ  AFSC.  The  RTO  is  normally  del¬ 
ineated  in  the  PMD.  The  program  manager  or  RTO  may  also  receive  assistance  from  a 
participating  test  organization  ( PTO ).  The  RTO  and  PTO  are  normally  chosen  from 
AFSC  test  resources,  such  as  the  Air  Force  Flight  Test  Center  (AFFTC),  Arnold 
Engineering  and  Development  Center  (AEDC),  Armament  Development  Test  Center 
(ADTC),  4950th  Test  Wing,  and  other  laboratories  and  centers. 

The  RTO  normally  appoints  a  test  manager  and  prepares  a  test  plan.  There 
may  be  a  feeling,  at  times,  that  the  RTO  has  usurped  the  power  of  the  program  manager 
in  its  actions.  The  truth  is  that  the  RTOs  function  is  to  test  and  maintain  a  capability 
in  test  management  and  test  facilities.  The  RTO  test  plan  is  submitted  to  the  program 
manager  for  approval  and  then  to  AFOTEC  for  review  and  comment.  The  RTO  then 
conducts  the  test  with  participation  by  AFOTEC  and  the  user/support  commands  as 
required.  The  report  is  normally  prepared  by  the  RTO  and  may  be  approved  for  publi¬ 
cation  by  the  RTO  or  the  program  manager.  Normal  coordination  procedures  would 
seem  to  dictate  that  the  program  manager  would  have  control  over  these  reports.  How¬ 
ever,  the  centers  are  justly  proud  of  their  objective  test  capability  and  ability  to  publish 
their  findings  with  integrity.  It  is  up  to  the  program  manager  to  resolve  any  problems 
that  impact  upon  his  program  as  a  result  of  the  RTO’s  rigorous  tests. 
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AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 

TEST  AND  EVALUATION 


The  primary  purpose  of  ail  T&E  is  to 
make  a  direct  contribution  to  the  timely 
development,  production,  and  fielding 
of  systems  that  meet  the  user’s 
requirements  and  are  operationally 
effective  and  suitable. 
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BACKGROUND 

LATE  1960'S  -  EARLY  1970's 


STUDIES 


•  BLUE  RIBBON  DEFENSE  PANEL 

•  COMMISSION  ON  GOVERNMENT 
PROCUREMENT 

•  GAO 

•  CONGRESS 

•  HQ  USAF  TEST  CONCEPT 
REVIEW  BOARD 


MAJOR  T  &  l  FINDINGS 

•  CONCURRENCY 

•  OVER  DEPENDENCY  ON  CONTRACTORS 

•  EARLIER  OPERATOR  FEEDBACK 

•  MORE  TIMELY  TEST  RESULT  REPORTING 

•  IMPROVED  OBJECTIVITY 


'  AIR  FORCE  INSTITUTE  OF  TECHNOLOGY'p* 


CURRENT  POLICY 

[DOD  DinECTIVE  5000.3) 


•  EARLY  IDENTIFICATION  OF  TEST  OBJECTIVES 

•  CONTINUOUS  TESTING  THROUGHOUT  ACQUISITION  PROCESS 

•  TEST  &  EVALUATION  MILESTONES  MET  PRIOR  TO  KEY  OECISIONS 

•  INDEPENDENT  AGENCY  RESPONSIBLE  FOR  OPERATIONAL  TESTING 

•  SEPARATE  FROM  DEVELOPER  AND  USER 

•  REPORTS  01RECTLY  TO  SERVICE  CHIEF 
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TEST  AND  EVALUATION 
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...conduct  of  appropriate  T&E  will  be  a 
key  requirement  for  decisions  to  commit 
significant  additional  resources  to  a 
program,  to  advance  it  from  one 
acquisition  phase  to  another, 
and  to  field  a  system. 


DODD  5000.3 


AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


AIR  FORCE 

OPERATIONAL  TEST  £  EVALUATION  CENTER 


•  SEPARATE  OPERATING  AGENCY 

«  INDEPENDENT  FROM  DEVELOPING  AND  USING  COMMANDS 

•  REPORTS  TO  AIR  FORCE  CHIEF  OF  STAFF 

•  PRINCIPLE  ELEMENTS: 


•  HEADQUARTERS 

•  FIELD  TEST  TEAMS 
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MANAGEMENT  OF  DT&E 

To  demonstrate  that 


■  Engineering  is  reasonably  complete 

■  All  significant  design  problems  are 
identified 

•  Solutions  to  these  problems  have  been 
developed 


AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


DT&E  OBJECTIVES 


•  Assess  the  critical  issues 

*  Determine  how  well  specifications  have 
been  met 
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AIR  FORCE  INSTITUTE  Of  TECHNOLOGY 


CRITICAL  ISSUES 


Those  aspects  of  a  system’s  capability, 
either  operational,  technical  or  other 
that  must  be  answered  before  a  system’s 
overall  worth  can  be  estimated,  and  that 
are  of  primary  importance  to  the 
decision  authority  in  deciding  to  allow 
the  system  to  advance  into  the  next 
acquisition  phase. 


DODD  5000.3-M-1 


AIR  FORCE  INSTITUTE  OF  TECHNOLOGY  | 

OT&E  MANAGEMENT 


fne  primary  purpose  of  OT&E  is  to  ensure 
that  only  operationally  effective  and 
suitable  systems  are  delivered  to  the 
operating  forces. 
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OT&E  MANAGEMENT 


OT&E  is  the  field  test,  under  realistic 
conditions,  of  any  item  of  weapons, 
equipment,  or  munitions  for  the  purpose 
of  determining  the  effectiveness  and 
suitability  of  the  weapons,  equipment, 
or  munitions  for  use  in  combat  by 
typical  military  users; 

and  the  evaluation  of  the  results  of 
such  tests. 


DODD  5000.3 


AIR  FORCE  INSTITUTE  OF 


TECHNOLOGY 


OT&E  OBJECTIVES 


■  Evaluate  operational  effectiveness 

■  Evaluate  operational  suitability 

■  Answer  unresolved  critical  operational 
issues 


14-16 


NCOS  M.  THC  ACQUSITIOH  PtOCSSS 


i  LESSON  15 

LESSON  TITLE:  Program  Control/Cost  Estimating 
TIME:  1.5  hrs 

LESSON  OBJECTIVE:  The  objective  of  this  lesson  is  for  each  student  to  know 
the  role  of  program  control  and  cost  estimating  in  the  management  of  an 
acquisition  program  and  how  the  WBS  facilitates  this  role. 

SAMPLES  OF  BEHAVIOR:  The  student  should: 

a.  List  the  three  divisions  of  program  control. 

b.  Describe  how  the  WBS  supports  the  program  control  and  cost  estimating 
function. 

c.  List  four  areas  of  the  budget  process. 

d.  Describe  the  characteristics  of  an  acceptable  cost  estimate. 

e.  List  the  various  categories  and  requirements  of  cost  estimates. 

f.  Outline  some  of  the  major  reasons  of  weapon  system  cost  growth. 

TOPIC  INTRODUCTION: 

Congratulations,  you  have  made  it  to  the  final  lesson  in  SYS  100.  Program 
Control/Cost  Estimating,  though  the  last  block,  does  not  imply  that  it  is  the  least 
important.  Rather,  this  block  tends  to  focus  all  the  functional  areas  in  one  important 
area  —  financial  management.  After  all,  if  you  did  not  have  the  funds  to  complete  a  pro¬ 
ject,  you  would  have  to  address  other  ways  to  still  meet  program  direction  or  reducing 
the  scope  of  the  program.  Program  Control  can  help  you  in  this  process,  by  providing 
\  the  necessary  information  on  which  to  make  important  program  decisions.  Program 

Control  can  assist  all  the  functional  divisions,  found  in  a  typical  System  Program  Office, 
by  being  the  cost  and  schedule  experts.  This  lesson  introduces  you  to  the  common  types 
of  work  found  in  Program  Control,  some  of  the  tools  used  to  track  costs  and  schedule, 
the  characteristics  of  cost  estimating,  and  some  o"  the  reasons  for  weapon  system  cost 
growth. 

You  will  probably  agree  that  this  is  a  lot  of  information  for  an  introductory  course. 
Unfortunately,  there  is  no  way  of  teaching  just  one  lesson  of  this  material  without  an 
appreciation  of  the  other  processes,  regulations,  and  disciplines  involved.  Fortunately, 
you  have  this  workbook  to  which  you  can  always  refer  in  the  future  and  build  upon  your 
acquisition  experiences. 

Good  Luck!!! 

METHOD  OF  INSTRUCTION:  Lecture/Discussion 
INSTRUCTIONAL  MATERIALS: 

a.  Article:  Program  Control  and  Cost  Estimating ,  by  Capt  Adler,  AFIT/LSY 
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b.  Program  Control!  Cost  Estimating  videotape 

c.  Lesson  viewgraphs 

AUDIO-VISUAL  AIDS:  Chalkboard 

INSTRUCTIONAL  EQUIPMENT:  Video  monitor  and  3/4"  tape  player 
REFERENCES: 

a.  AFSCP  800-3,  A  Guide  for  Program  Management 

b.  AFR  800-25,  Acquisition  Program  Baselining 

c.  MIL-STD-881A,  Work  Breakdown  Structure  for  Defense  Material  Items 

d.  AFR  800-17,  Work  Breakdown  Structure  (WBS)  for  Defense  Material  Items 

e.  AFR  173-1,  The  Air  Force  Cost  Analysis  Program 

REQUIRED  STUDENT  PREPARATION: 

a.  Read  article:  Program  Control  and  Cost  Estimating 

b.  Scan  lesson  viewgraphs 

DISCUSSION  QUESTIONS: 

.As  program  manager,  you  have  been  tasked  to  provide  and  present  a  cost  estimate 
on  your  program  for  AFSARC  review.  Your  program  is  a  Non-Major  program  in  Full- 
Scale  Development  and  has  a  one-year  old  cost  estimate.  You  want  to  update  your  cost 
estimate,  because  of  all  the  changes  that  have  impacted  your  program,  and  you  want  to 
see  what  impact  these  have  on  the  cost  of  the  program.  To  assist  you,  the  Comptroller 
has  provided  a  new  cost  analyst  to  your  program  office. 


1.  What  factors  do  you  consider  most  important  in  bringing  the  cost  analyst  onto 
your  acquisition  team? 


2.  What  factors  do  you  think  might  be  encountered  in  developing  and  presenting  a 
cost  estimate,  with  regard  to  weapon  system  cost  growth? 


3.  What  information  will  the  cost  analyst  need  to  complete  the  estimate,  and  why 
is  it  important?  Is  it  always  possible  to  get  the  information  you  need?  What  might  con¬ 
strain  the  information  gathering  process? 
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4.  Your  new  Program  Control  Chief  is  considering  ways  to  improve  the  program 
evaluation  process  within  your  program  office.  In  order  to  do  this,  you  need  a  complete 
analysis  of  what  program  control’s  responsibilities  include.  What  is  the  primary  role  of 
program  control,  and  what  issues  and  items  should  you  address  first  with  the  new  Pro¬ 
gram  Control  Chief? 


[Acronyms  introduced  in  this  lesson,  and  their  description] 
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BES  Budget  Estimate  Submission 

C/SCSC  Cost/Schedule  Control  Systems  Criteria 

C/SSR  Cost/Schedule  Status  Reviews 

CFSR  Contract  Funds  Status  Reports 

CPR  Cost  Performance  Reports 

EAC  Estimate  at  Completion 

ICA  Independent  Cost  Analysis 

XCS  Independent  Cost  Study 

XSA  Independent  Schedule  Assessment 

ISR  Independent  Sufficiency  Review 
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MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS-  1963-A 


PROGRAM  CONTROL 


AND 

COST  ESTIMATING 

The  Air  Force  program  manager  is  the  single  point  of  responsibility  in  acquiring 
and  deploying  weapon  systems  to  satisfy  operational  needs.  The  program  control  direc¬ 
torate,  which  serves  the  program  manager,  attempts  to  facilitate  the  goal  of  producing 
systems  within  schedule  and  acceptable  cost  constraints  while  meeting  performance  and 
logistic  supportability  requirements.  Program  control  personnel  frequently  develop  key 
contacts  in  and  out  of  the  government  to  carry  out  their  responsibilities.  They  essen¬ 
tially  become  filter  devices  of  information  to  the  program  manager  so  that  issues  and 
challenges  are  elevated  and  answered  quickly  and  thoroughly.  Sometimes  informal  con¬ 
tacts  may  be  the  best  avenues  for  controlling  costs,  schedule,  performance,  or  supporta¬ 
bility. 

Functionally,  program  control  is  typically  divided  into  three  unique  divisions 
depending  on  the  type  of  work  involved.  The  program  evaluation  division  deals  with  the 
contractor  while  monitoring  the  costs  of  the  program;  the  financial  management  division 
focuses  on  identifying  and  monitoring  funds  to  keep  the  program  moving;  and  the  plans 
and  integration  division  deals  with  non-financial  aspects  of  the  System  Program  Office 
(SPO)  like  planning,  scheduling,  and  forecasting.  Some  program  offices  may  not  be 
organized  this  way,  but  the  type  of  work  done  in  each  division  is  typical  of  what  goes  on 
in  any  program  control  directorate.  The  following  is  a  summary  analysis  of  the  special 
considerations  of  each  program  control  division. 

Program  evaluation  is  really  program  analysis  of  costs  in  support  of  the  financial 
manager.  By  interfacing  with  the  financial  managers,  program  evaluation  identifies  the 
cost  requirements  and  the  cost  performance  of  the  contractor.  Some  activities  one  nor¬ 
mally  finds  in  program  evaluation  are  Cost/  Schedule  Control  Systems  Criteria 
( CfSCSC)  and  Cost  Analysis.  C/SCSC  deals  with  performance  measurement  using  Cost 
Performance  Reports  ( CPR ),  Contract  Funds  Status  Reports  ( CFSR),  and  Cost/Schedule 
Status  Reviews  ( C/SSR )  all  used  to  track  and  analyze  the  contractor’s  performance.  The 
emphasis  in  cost  analysis,  from  a  program  control  perspective,  is  in  tying  the  contractor’s 
Estimate  At  Completion  ( EAC)  to  your  SPO  budget. 

Some  of  the  end  products  of  program  evaluation  are  selection  of  the  best  contrac¬ 
tor  in  source  selections,  periodic  review  of  the  SPO  estimate  for  sufficiency,  Program 
Objective  Memorandum  ( POM)  or  Budget  Estimate  Submission  ( BES)  budget  support 
with  financial  managers,  future  billings  and  budget  forecasts,  and  support  for  impact 
statements  and  what-if  exercises  in  budget  and  briefing  cycles. 

Financial  management,  on  the  other  hand,  deals  with  the  management  of  pro¬ 
gram  funds  and  the  process  of  budget  requests.  Some  fee;  this  is  the  heart  of  any  pro¬ 
gram  since  if  you  did  not  have  funds  to  run  your  program,  you  would  not  have  a  pro¬ 
gram.  Typical  financial  management  functions  are  budgeting,  financial  analysis,  fund 
administration,  fiscal  integrity  and  accountability,  appropriation  integrity,  and  support 
of  the  program  manager.  Fiscal  integrity,  for  example,  means  using  FY85  dollars  for  the 
approved  FY85  program,  FY86  dollars  for  the  FY86  program  and  so  on.  Appropriation 
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integrity  means,  for  example,  that  3010  money  will  be  used  to  procure  aircraft  or  that 
3020  money  will  be  used  to  procure  missiles. 

Financial  Management  end  products  include  the  POM  and  BES,  fund  status, 
funding  documents,  and  the  program  baseline.  The  POM  identifies  total  program 
requirements  in  ranked  format  for  the  next  five  years,  and  includes  rationale  in  support 
of  the  planned  changes  from  the  approved  Five  Year  Defense  Program  ( FYDP )  Baseline. 
The  POM  is  based  on  strategic  concepts  and  guidance  stated  in  the  Defense  Guidance 
and  includes  an  assessment  of  the  risk  associated  with  current  and  proposed  forces.  The 
BES  is  a  recosting  of  the  POM  as  modified  by  the  Program  Decision  Memorandum 
(PDM).  It  should  be  noted  that  new  requirements  cannot  be  introduced  in  the  BES,  only 
in  the  POM.  Another  end  product  of  financial  management  is  the  status  of  funds. 
Weighing  the  contractors  EAC  to  the  SPO’s  budget  is  a  daily  activity.  At  any  time,  a 
financial  analyst  should  be  able  to  provide  the  status  of  3600,  3080,  3010,  or  3020  funds 
with  regard  to  expenditures  and  obligations.  The  following  definitions  describe  common 
financial  terms  and  concepts: 

Obligation  —  Legally  binding  contract  between  government  and  contractor. 

Commitment  —  SPO  or  Comptroller  administrative  reservation  of  funds 
for  future  use. 

Expenditure  —  Actual  payment  of  money  to  contractor. 

Plans  and  integration  functions  include  scheduling,  documentation  review,  pro¬ 
gram  analysis,  computer  support,  and  reports  control.  A  key  element  in  scheduling  is 
the  Integrated  Master  Schedule.  An  integrated  master  schedule  is  a  detailed  program 
schedule  that  portrays  all  of  the  major  elements  of  a  program  and  all  related  develop¬ 
ment  efforts  so  that  the  interrelationships  are  easily  seen.  Since  it  is  the  integrated 
schedule,  it  is  updated  regularly  and  is  recognized  as  the  only  authorized  source  for  pub¬ 
lication  of  schedule  information  outside  the  program  office.  The  other  functions  of  plans 
and  integration  deal  with  supporting  the  program  manager  in  non-financial  aspects.  For 
instance,  documentation  reviews  are  held  to  analyze  all  descriptive  information  concern¬ 
ing  activities  between  federal  agencies  and/or  the  contractor.  These  documents  usually 
delineate  policy  or  elevate  issues  so  that  options  can  be  addressed.  In  a  system  of  plans, 
the  program  manager’s  (and  the  team’s)  strategy  to  achieve  the  objective  is  integrated  in 
the  Program  Management  Plan  and  detailed  in  plans  such  as  the  Acquisition  Plan,  Test 
and  Evaluation  Master  Plan,  Integrated  Logistics  Support  Plan,  and  lower-level  func¬ 
tional  plans. 

End  products  associated  with  plans  and  integration  include  the  master  integrated 
schedule,  internal  reports,  and  ensuring  that  the  Program  Management  Directive  and 
AFSC  Form  56  are  valid  and  current. 

In  discussing  how  program  control  supports  the  program  manager,  one  needs  to 
realize  that  there  is  a  close  relationship  between  plans,  schedules,  cost  estimates,  and 
budgets  and  how  they  all  form  the  program  baseline.  The  baseline  is  the  standard  or 
yardstick  through  which  program  status  is  determined  and  potential  problems  are 
identified.  To  perform  these  functions  then,  some  program  infrastructure  is  required. 
Some  method  for  relating  the  parts  to  the  whole  and  aggregating  information  at  an 
appropriate  level  of  detail  is  essential.  The  Work  Breakdown  Structure  (WBS)  is  the 
infrastructure  or  vehicle  doing  this.  A  WHS  L  a  product-oriented  family  tree  composed 
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of  hardware,  services,  and  data  which  results  from  project  engineering  efforts  during 
development  and  production  of  a  defense  system  or  equipment  item,  and  which  com¬ 
pletely  defines  the  project/program.  A  WBS  displays  and  defines  the  product(s)  to  be 
developed  or  produced  and  relates  the  elements  of  work  to  be  accomplished  to  each  other 
and  to  the  end  product.  Each  WBS  is  constructed  in  levels.  Level  one  is  the  entire  sys¬ 
tem  or  item:  for  example,  the  E-3A  Sentry  AWACS  system.  Level  two  consists  of  the 
major  elements  of  the  system:  for  example,  an  air  vehicle,  data,  or  aggregations  of  ser¬ 
vices  such  as  system/project  management  and  system  test  and  evaluation.  Level  three  is 
the  next  level  of  decomposition  of  the  entire  system  into  its  components.  Level  three  ele¬ 
ments  would  include  the  attitude  control  subsystem,  or  a  specific  type  of  service  or  data 
such  as  development  test  and  evaluation  or  engineering  data,  l/ower  levels  are  identified 
as  necessary  to  completely  define  the  elements  of  the  program.  MU/-STD-881-A  and  AKU 
800-17  provide  policy  and  guidance  on  the  WBS. 

The  WBS  supports  the  program  control  and  cost  estimating  function  by  being 
the  foundation  for  all  SPO  discussion  on  costs,  plans,  and  schedules  both  within  the 
government  and  between  the  government  and  the  contractor.  The  WBS  provides  a  way 
for  people  of  various  backgrounds  and  perspectives  to  talk  intelligently  about  issues 
important  to  everyone  in  the  SPO.  The  work  breakdown  structure  permeates  the  pro¬ 
gram  in  all  management  areas:  planning,  organizing,  directing,  and  controlling. 

Let’s  address  the  four  areas  of  the  budgetary  process.  The  first  is  budget  formu¬ 
lation.  Program  Control’s  involvement  is  most  extensive  in  this  phase  since  this  is  where 
the  SPO  budget  is  formulated.  This  budget  is  based  on  the  required  costs  necessary  to 
satisfy  program  requirements.  Cost  estimating  is  the  important  activity  here  in  the 
budgetary  process  because  this  is  where  costs  are  developed  and  identified.  Usually,  SPO 
budgets  are  based  on  validated  cost  estimates  or  cost  estimates  that  have  been  reviewed 
and  approved  based  on  consistency,  completeness,  reasonableness,  and  documentation. 
Once  the  budget  is  formulated,  the  program  manager  agrees  to  delivering  a  weapon  sys¬ 
tem  for  a  certain  cost  and  this  is  documented  in  the  program  baseline. 

The  second  phase,  enactment,  is  getting  authorization  and  hence,  appropriated 
funds  designated  for  your  program.  The  best  way  to  win  your  case  for  appropriated 
funds  is  through  good  documentation.  Good  documentation  can  highlight  the  impor¬ 
tance  of  your  program  especially  when  congressional  interest  is  high.  It  is  this  type  of 
justification  that  leads  to  an  approved  program. 

The  execution  phase  involves  putting  approved  funds  to  work  and  the  fourth 
budgetary  area  is  analysis  and  reporting.  The  analysis  and  reporting  phase  involves  all 
activities  in  support  of  the  Air  Force  briefing  process.  The  main  concept  behind  the 
briefing  process  is  to  resolve  issues  before  they  become  critical  by  presenting  cost  and 
schedule  information  to  those  in  higher  decision  positions. 

We  have  been  addressing  the  unique  and  interrelated  functions  in  acquisition 
management  throughout  this  course.  One  function  of  acquisition  management  that  gets 
a  lot  of  public  attention  is  military  acquisition  costs.  One  cannot  escape  the  attention 
given  to  military  costs  in  most  trade  journals,  major  newspapers,  and  other  forms  of 
media.  Suffice  it  to  say  that  military  performance  is  tied  directly  to  cost  effectiveness. 
The  peacetime  measurement,  of  how  are  we  doing  has  been  attached  to  costs,  or  more 
exactly,  cost  estimates.  Cost  estimating  is  the  basis  upon  which  budgets  are  formulated 
and  revised.  A  program’s  cost  estimate,  therefore,  is  that  baseline  or  anchor  that  keeps 
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the  program’s  costs  tied  to  a  number  representing  the  program’s  key  elements  with 
corresponding  dollar  values.  When  all  these  dollars  are  summed  into  the  Department  of 
Defense’s  ( DOD )  budget,  or  Total  Obligation  Authority,  it  takes  up  a  sizable  portion  of 
our  nation’s  tax  dollars.  Therefore,  it  is  no  wonder  that  so  much  attention  is  given  to 
the  DOD  budget  and  to  our  cost  estimating  process. 

The  acquisition  process  requires  and  focuses  on  the  cost  estimate  of  a  system  and 
the  availability  of  adequate  funding  levels  at  the  proper  time.  It  is  mandatory  that  cost 
estimates  accurately  reflect  program  financial  requirements.  A  program’s  viability  can  be 
seriously  impacted  if  measured  against  a  less  than  competent  estimate.  Any  discussion 
of  cost  estimating  usually  begins  with  a  definition.  Cost  estimating  is  defined  in  AFSCM 
173-1,  Cost  Analysis  Procedures,  as  .  .  .  the  process  of  projecting  financial  requirements 
to  accomplish  a  specified  objective.  It  includes  selecting  estimating  structures;  collecting, 
evaluating,  and  applying  data;  choosing  and  applying  estimating  methods;  and  providing 
full  documentation.  Additionally,  it  should  be  emphasized  that  the  cost  estimating  pro¬ 
cess  occurs  at  a  specific  point  in  time  and,  therefore,  is  as  accurate  as  the  information 
used  in  its  formation. 

Key  to  understanding  the  cost  estimating  process  is  an  appreciation  of  its  itera¬ 
tive  and  dynamic  nature.  One  program  may  go  through  multiple  cost  estimating  pro¬ 
jects  dependent  on  the  acquisition  or  budget  cycle.  Cost  estimates,  therefore,  serve 
several  functions.  One  is  to  provide  key  information  early  in  a  program’s  life  in  the 
establishment  of  a  program  baseline.  At  this  point  in  a  program’s  life  cycle,  it  is  crucial 
to  develop  as  accurate  a  cost  estimate  as  possible  because  many  complex  and  important 
decisions  are  made,  based  on  this  estimate,  that  affect  the  program  throughout  the 
program’s  life  until  disposal.  Remember  the  discussion  on  Integrated  Logistics  Support 
which  identified  that  seventy  percent  of  the  life  cycle  costs  of  a  system  are  committed  by 
Milestone  One,  by  Milestone  Two,  eighty-five  percent  and  by  Milestone  Three,  about 
ninety-five  percent.  Intuitively,  early  program  cost  estimates  are  crucial  to  a  program’s 
success. 

On  the  Product  Division  staff,  the  Comptroller  serves  as  an  independent  check  of 
the  SPO  cost  estimate.  Generally,  there  are  also  four  categories  of  cost  analysis  that  the 
Comptroller  may  perform  using  Program  Control  representatives.  These  include  the 
Independent  Cost  Analysis  ( ICA )  required  on  all  major  programs,  the  Independent  Cost 
Study  {ICS),  the  Independent  Sufficiency  Review  ( ISR ),  and  the  Independent  Schedule 
Assessment  {ISA). 

HQ  USAF/ACC  manages  the  ICA  program  based  on  APR  173-1.  An  ICA  is  a 
complex  effort  requiring  a  life  cycle  cost  estimate  for  the  Defense  Acquisition  Board 
{DAB)  and/or  the  Air  Force  Systems  Acquisition  Review  Council  {AFSARC).  ICAs  also 
include  a  detailed  risk  assessment  and  sensitivity  analysis. 

The  ICS  is  unique  in  that  it  can  be  generated  in  the  program  office  or  by  the 
comptroller  depending  on  who  tasked  the  requirement  for  the  cost  estimate.  The  ICS 
has  less  scope  than  an  ICA  since  there  is  no  life  cycle  cost  estimate  requirement. 

The  ISA  features  an  analysis  of  the  program  schedule  and  milestones  for  reason¬ 
ableness  and  consistency  with  current  direction. 

The  ISR  is  used  to  analyze  the  SPO  cost  estimate  for  completeness,  reasonable¬ 
ness,  consistency,  and  documentation.  The  key  is  the  independent  nature  of  the  ISR  as  a 
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check  on  the  accuracy  of  the  SPO  estimate. 

These  cost  estimates,  subsequently,  are  required  for  development  and  representa¬ 
tion  of  program  costs  in  the  budgetary  and  acquisition  cycles.  Cost  estimates  are  com¬ 
monly  required  for  each  Milestone  decision,  for  impact  studies  when  the  program’s  techn¬ 
ical  content  changes,  if  previous  cost  estimates  are  obsolete,  and  upon  direction  or  task¬ 
ing  to  do  so.  Cost  estimates  are  also  used  in  source  selections  to  provide  support  infor¬ 
mation  for  comparison  with  contractor  proposals.  The  type  of  cost  estimate  greatly 
depends  on  the  requirement,  program  information  available,  and  time  allowed  for  esti¬ 
mate  development. 

Understanding  the  characteristics  of  an  acceptable  cost  estimate  will  also  be  of 
assistance  in  presenting  program  information  efficiently  and  effectively.  The  first  charac¬ 
teristic  is  completeness.  A  cost  estimate  should  include  everything  that  the  SPO  has 
been  tasked  to  do  and  deliver.  Specifically,  all  costs  must  be  inflated  correctly  and 
included  in  the  estimate.  These  costs  must  conform  to  the  WBS  format  and  be  based  on 
actual,  current  information.  Efforts  must  be  made  to  ensure  costs  included  in  the  esti¬ 
mate  are  pertinent  to  the  program. 

The  second  characteristic  is  reasonableness.  The  cost  estimate  methodology  and 
logic  should  agree  with  current  policies  and  should  be  appropriate  for  the  program  being 
estimated.  Any  data  bases  used  as  references  in  the  cost  estimate  should  be  valid  and 
applicable.  The  assumptions,  learning  curve,  and  other  factors  used  in  the  estimate 
should  be  reasonable  and  applicable. 

The  third  characteristic  of  a  good  cost  estimate  is  consistency.  Any  inconsisten¬ 
cies  between  the  cost  estimate  and  acquisition  strategy  are  analyzed.  The  SPO’s  acquisi¬ 
tion  strategy  or  plan  should  subsequently  be  consistent  with  the  latest  program  direction 
and  schedule.  All  ground  rules  and  assumptions  made  in  the  cost  estimate  should  be 
consistent  with  current  direction.  Any  differences  between  the  cost  estimate  and  previous 
estimates  are  addressed  and  analyzed. 

Finally,  the  last  characteristic  of  a  good  estimate  is  quality  documentation. 
Documentation  must  be  clear,  concise,  and  explicit  in  supporting  statements  made  in  the 
cost  estimate.  Documentation  must  be  presented  and  organized  in  accordance  with  AFR 
173-1. 

Documentation  should  clearly  explain  how  the  estimate  was  developed,  what 
methods  were  used  in  each  WBS  area,  what  models  were  used  to  generate  costs  and  the 
projected  accuracy  of  the  model’s  estimated  costs  pertaining  to  your  program,  the  team 
members  involved  who  developed  the  cost  estimate,  and  the  logic  behind  the  estimate’s 
creation  and  organization.  Documentation  is  the  key  to  separating  a  good  estimate  from 
a  bad  one  for  the  single  reason  that  the  estimate  can  be  reviewed,  updated,  or  analyzed 
by  others  separate  from  the  program  or  comptroller.  Because  of  the  iterative  nature  of 
the  acquisition  process,  one  program  can  easily  go  through  multiple  cost  estimates  in  its 
life  time.  A  common  thread  needs  to  flow  from  one  cost  estimate  to  the  next,  if  possible. 
Documentation  facilitates  this  flow,  especially  when  the  original  cost  estimator  on  that 
program  probably  will  not  be  the  same  estimator  on  that  program  ten  or  even  five  years 
down  the  road.  Documentation  is  a  valuable  resource  in  cost  estimating  because  it  pro¬ 
vides  a  means  of  transferring  logic  and  thought  across  time,  as  a  program  is  being 
developed,  for  showing  the  logic  behind  important  decisions  or  reasons  for  historical  cost 
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growth. 

Since  the  public  is  so  interested  in  the  cost  growth  of  military  systems,  one  needs 
to  have  an  appreciation  for  the  basic  reasons  that  drive  this  cost  growth.  One  historical 
factor  that  has  led  to  weapon  system  cost  growth  is  the  loss  of  estimating  expertise  con¬ 
tinuity.  Failure  to  analyze  program  costs  the  same  way  or  with  the  same  objectives  or 
background  leads  to  inconsistencies.  Documentation  can  help  alleviate  this  problem.  A 
second  potential  factor  is  the  use  of  historical  costs  for  gauging  future  program  costs.  Is 
it  correct  to  assume  that  current  programs  under  development  now  will  follow  cost  pat¬ 
terns  of  historical  weapon  systems?  Most  in  the  cost  field  agree  historical  costs  are 
usable  but  with  certain  constraints.  Usually  programs  use  adjustment  factors  to  tailor 
their  program  costs  by  comparing  their  system  and  their  estimated  costs  with  the  costs 
of  historical  programs.  These  comparisons  are  useful  and  necessary  in  providing  the 
basis  on  which  to  estimate  and  present  costs.  Subsequently,  new  cost  estimating 
methods  are  constantly  being  developed  in  order  to  refine  and  improve  the  use  of  histori¬ 
cal  costs.  Other  cost  growth  factors  include  limited  program  definition,  difficulty  quanti¬ 
fying  program  risk,  limited  funding,  questionable  material  availability,  and  the  overall 
failure  to  include  all  costs.  Trying  to  account  for  these  factors  when  developing  a 
program’s  estimated  cost  is  best  left  up  to  people  with  the  corporate  knowledge  and 
expertise  in  doing  cost  estimates,  usually  Program  Control  and  Comptroller  personnel. 
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Defense  Resources  Board 

Data  Requirements  Review  Board 

Depot  Support  Requirements  Document 

Defense  Standardization  &  Specification  Program 

Development  Test  and  Evaluation 

Estimate  at  Completion 

Engineering  Change  Proposals 

Engineering  Data  Management  Officer 

Federal  Acquisition  Regulation 

Functional  Configuration  Audit 

Firm  Fixed-Price 

Fully  Mission  Capable 

Follow-On  Operational  Test  and  Evaluation 

Fixed-Price  Incentive 

Formal  Qualification  Review 

Full  Scale  Development 

Five  Year  Defense  Program 

General  Accounting  Office 

Government  Bill  of  Lading 

Government  Furnished  Property 

Independent  Cost  Analysis 

Intercontinental  Ballistic  Missile 

Independent  Cost  Study 

Interface  Design  Documents 

Invitations  for  Bids 

Integrated  Logistics  Support 

Integrated  Logistics  Support  Manager 

Integrated  Logistics  Support  Plan 

Industrial  Modernization  Incentive  Program 

Initial  Operational  Capability 

Initial  Operational  Test  and  Evaluation 

Issue  Paper 

Integrated  Program  Summary 
Independent  Schedule  Assessment 
Independent  Sufficiency  Review 
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JPAM 

JSOR 

JSPD 

JT&E 

JTD 

JTF 

LCC 

LRIP 

LSA 

MAR 

MNS 

MST&E 

O&M 

OMB 

OPR 

OT&E 

PAD 

PCA 

PCO 

’DM 

PDP 

PDR 

P3I 

PEM 

PEO 

PFRS 

PHS&T 

PM 

PMD 

PMP 

PMRT 

PO 

POM 

PPBS 

PR 

PRO 

PRR 

PTO 

QOT&E 

QT*E 

RfcM 

RCM 


Joint  Chiefs  of  Staff 
Joint  Program  Assessment  Memorandum 
Joint  Systems  Operational  Requirement 
Joint  Strategic  Planning  Document 
Joint  Test  and  Evaluation 
Joint  Test  Director 
Joint  Task  Force 
Life  Cycle  Cost 
Low  Rate  Initial  Production 
Logistics  Support  Analysis 
Management  Assessment  Reviews 
Mission  Need  Statement 
Multi-Service  Test  and  Evaluation 
Operation  and  Maintenance 
Office  of  Management  and  Budget 
Office  of  Primary  Responsibility 
Operational  Test  and  Evaluation 
Program  Action  Directive 
Physical  Configuration  Audit 
Procuring  Contracting  Officer 
Program  Decision  Memorandum 
Program  Decision  Package 
Preliminary  Design  Review 
Preplanned  Product  Improvement 
Program  Element  Monitor 
Program  Executive  Officer 
Program  Financial  Reviews 

Packaging,  Handling,  Storage  &  Transportation 
Program  Manager 
Program  Management  Directive 
Program  Management  Plan 

Program  Management  Responsibility  Transfer 
Program  Office 

Program  Objective  Memorandum 

Planning,  Programming  and  Budgeting  System 

Purchase  Request 

Plant  Representative  Office 

Production  Readiness  Review(s) 

Participating  Test  Organization 
Qualifying  Operational  Test  k  Evaluation 
Qualification  Test  and  Evaluation 
Reliability  and  Maintainability 
Requirements  Correlation  Matrix 


A- 3 


RDT&E 

RFP 

RFQ's 

RTO 

SAF 

SAFPAR 

SAR 

SCP 

SDDD 

SDR 

SE 

SECDEF 

SOA 

SOC 

SON 

SORD 

SOW 

SPO 

SRR 

SSA 

SSAC 

SSEB 

SSP 

SSR 

SYSTO 

T4E 

TBD 

TCO 

TEMP 

TOs 

TPWG 

TRR 

WBS 


Research,  Development,  Test  and  Evaluation 
Request (s)  for  Proposal 
Requests  for  Quotations 
Responsible  Test  Organization 
Secretary  of  the  Air  Force 

Secretary  of  the  Air  Force  Program  Assessment  Review 

Selected  Acquisition  Reports 

System  Concept  Paper 

Software  Detail  Design  Documents 

System  Design  Review 

Support  Equipment 

Secretary  of  Defense 

Separate  Operating  Agencies 

System  Operational  Concept 

Statement  of  Operational  Need 

System  Operational  Requirements  Document 

Statement  of  Work 

System  Program  Office 

System  Requirements  Review 

Source  Selection  Authority 

Source  Selection  Advisory  Council 

Source  Selection  Evaluation  Board 

Source  Selection  Plan 

Software  Specification  Review 

Systems  Officer 

Test  and  Evaluation 

To  Be  Determined 

Termination  Contracting  Officer 

Test  and  Evaluation  Master  Plan 

Technical  Order (s) 

Test  Plan  Working  Group 
Test  Readiness  Review 
Work  Breakdown  Structure 
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